Tables in the contain various configuration options that can impact performance, reduce storage requirements, or provide extra data safeguards. As some table configuration options cannot be added after data is already loaded, it is important that you take the time to designDocumentation Index
Fetch the complete documentation index at: https://docs.ocient.com/llms.txt
Use this file to discover all available pages before exploring further.
CREATE TABLE SQL statements with forethought for the queries that you expect to execute frequently. This topic provides examples of CREATE TABLE SQL statements designed for different use cases and describes the configuration choices.
For syntax and parameter information, see CREATE TABLE .
Create a Table with All Data Types
This example creates a table with all supported data types in . The intent of this example is to show the required formatting for different data type values, which is shown as theDEFAULT value for each column.
SQL
Create a Table for Real-Time Analysis
This example assumes you plan to ingest large quantities of time series data for rapid querying. The most important columns that you plan to reference in queries frequently include:created_at— A granular timestamp column that represents the primary time reference in the table.user_id— An integer column to identify each unique user.sell_id— An integer column representing each transaction by a user.
SQL
| Column Name | Configuration Description |
|---|---|
created_at | This column is the table , which means that the database indexes for filter optimization. The example configures the TimeKey to partition segments by every hour, (1, HOUR), which is the approximate time granularity you expect to use in your query filters. |
user_id, sell_id | The example table identifies these two columns as the table Clustering Key. The database pairs these two columns for quick reference, such as filtering one column for row values of the other. |
purchase_amount | The CREATE INDEX SQL statement adds a secondary index to this column. As a BIGINT data type, the purchase_amount column defaults to the INVERTED index. |
buyer_name | This CREATE INDEX SQL statement adds a secondary index to this column. As a VARCHAR column, the buyer_name column normally defaults to a HASH index, but this example specifies it should be an NGRAM index of width 4 instead. |
Create a Table for Geospatial Data
This example assumes you plan to ingest geospatial data linked to time series data using . The most important columns that you plan to reference frequently in queries include:route_time— A granular timestamp column that represents the primary time reference in the table.start_point,end_point— The geospatial point values for the start and destination locations.trip_id— An integer column to identify each unique trip.vehicle_id— An integer column that represents each vehicle.
SQL
| Column Name | Configuration Description |
|---|---|
route_time | This column is the table TimeKey, which means that the database indexes for filter optimization. The example configures the TimeKey to partition segments by every two weeks (14, DAY), which is the approximate time granularity that you expect to use in your query filters. |
trip_id, vehicle_id | The example table identifies these two columns as the table Clustering Key. The database pairs these two columns for quick reference, such as filtering one column for row values of the other. |
end_point, route_path, route_area | These columns have POINT, LINESTRING, and POLYGON data types, respectively. Each of these geospatial columns includes default values in its respective format. |
start_point, end_point | The CREATE INDEX SQL statements for both of these columns assign SPATIAL indexes for quicker reference. This index is the default type for any column with a geospatial data type. |
Create a Table With Compression Options
This example table includes multiple compression options to ensure minimal storage for specific columns and extra performance.Most data types, except arrays, have
COMPRESSION DYNAMIC applied by default.SQL
| Column name | Configuration Description |
|---|---|
address | This column explicitly removes compression by specifying COMPRESSION NONE in the CREATE TABLE SQL statement. |
call_type, access_information | These columns have VARCHAR data types configured with Global Dictionary Compression (GDC). This compression scheme maps the variable-length type rows to integers. Among other benefits, this compression allows both columns to support a Clustering Key for faster querying. The call_type column stacks multiple compression schemes by including both GDC and ZSTD compression to provide additional storage reduction. |
file_name | This column uses ZSTD compression with extra options. The compression_level is set for 3, meaning the column data is slightly more compressed than the default 0. The dictionary_size is set for the maximum value, 1048576, which means greater compression but higher memory demand. |
Create a Table for Various Container Types
This example table includes complex container data types, including a two-dimensional array, a tuple with variable-length values, and a tuple with various data types.SQL
| Column name | Configuration Description |
|---|---|
point_array_col | This column is an array of POINT values that is indexed using a SPATIAL index type as specified by the CREATE INDEX SQL statement. |
tuple_col1 | This tuple column contains two variable-length values. Each object in the tuple can support its own compression scheme and index. The CREATE INDEX SQL statement assigns a HASH index to the first value (VARCHAR(255)). |
tuple_col2 | This tuple column contains various data types. Each object in the tuple can support its own compression scheme and index. The two VARCHAR objects in the tuple column each have their own unique compression scheme. The CREATE INDEX SQL statement assigns an INVERTED index to the second tuple object, the integer array INT[]. |
Create a Table With a Retention Policy
This example creates a retention policy that keeps rows only if they are less than one day old, as specified by the last line,RETENTION POLICY AGE 1 DAY. The retention policy depends on the created_at column because it is the TimeKey column. The TimeKey bucket value (1, HOUR) determines how frequently the system checks for any rows to remove.
SQL

