FAQ and Known Limitations¶
This page contains information that doesn’t fit into other pages or is important enough to be called out separately. If you have a question or tidbit of information that you feel should be included here, please create an issue and/or pull request to get it added to this page.
While we strive to keep this page updated, bugfixes and new features are being added regularly. If information on this page conflicts with your experience, please open an issue or drop by our Community forum to get clarification.
select_ipc_gpu()give me errors, but
select_ipc_gpu()require running the pymapd code on the same machine where OmniSci is running. This also implies that these two methods will not work on Windows machines, just Linux (CPU and GPU) and OSX (CPU-only).
Why do geospatial data get uploaded as
TEXT ENCODED DICT(32)?
create='infer', data where type cannot be easily inferred will default to
TEXT ENCODED DICT(32). To solve this issue, create the table definition before loading the data.
- Convert your timestamps to UTC
OmniSci stores timestamps as UTC. When loading data to OmniSci, plain Python
datetimeobjects are assumed to be UTC. If the
datetimeobject has localization, only
datetime64[ns, UTC]is supported.
- When loading data, hand-create table schema if performance is critical
load_table()does provide a keyword argument
createto auto-create the table before attempting to load to OmniSci, this functionality is for convenience purposes only. The user is in a much better position to know the exact data types of the input data than the heuristics used by pymapd.
Additionally, pymapd does not attempt to use the smallest possible column width to represent your data. For example, significant reductions in disk storage and a larger amount of ‘hot data’ can be realized if your data fits in a
TINYINTcolumn vs storing it as an
Be careful using pymapd on 32-bit systems, as we do not check for integer overflow when returning a query.
DECIMALtypes returned as Python
OmniSci stores and performs
DECIMALcalculations within the database at the column-definition level of precision. However, the results are currently returned back to Python as float. We are evaluating how to change this behavior, so that exact decimal representations is consistent on the server and in Python.