The following examples demonstrate how to use HeavyConnect using the foreign data wrappers, servers, tables, and user mappings. The examples use the following directory structure and underlying Parquet files. The highlighted numbers on the graphic correspond to the numbered examples that follow.
Details of the commands used in the examples are available in the Command Reference.

HeavyConnect to the Parquet data organized in the year 2020. Users expect monthly updated data that has been added to existing data.
You can now query and build dashboards using the foreign table example_year_2020.
HeavyConnect to the Parquet data organized in the month of March. Users expect weekly updated data that has been added to the existing data.
When specifying a file path in the foreign table creation statement, the path is additive to the base path specified in the foreign server.
You can now query and build dashboards using the foreign table example_month_march.
HeavyConnect to the Parquet data Mar_01_2020. Users expect daily updated data that may have been edited throughout the file.
REFRESH_UPDATE_TYPE=‘ALL’ instructs the system to update all metadata and takes additional time for larger datasets. This can have an impact on performance when used with a short REFRESH_INTERVAL.
You can now query and build dashboards using the foreign table example_day_march_01.
HeavyConnect to the Parquet data of year-over-year (YoY) January data. Users manually refresh the data that has been updated throughout the file.
To refresh the data, you need to issue the command REFRESH FOREIGN TABLES example_yoy_january.
You can now query and build dashboards using the foreign table example_yoy_january.
This example provides the full workflow required to HeavyConnect to a private S3 Parquet datastore.
See the AWS documentation for information on organizing your data and how folders are represented in S3.
You can now query and build dashboards using the foreign table example_year_2020.
This example provides the full workflow required to HeavyConnect to a public S3 CSV datastore that uses the S3 Select access type.
You can now query and build dashboards using the foreign table example_year_2020.
This example illustrates how the regex parsed file data wrapper can be used to query a local log file, which uses the Common Log Format standard. Assume that the log file has the following content:
Create a foreign table that extracts all the fields in the logs:
Tip: Use a regex visualizer tool with a sample of the text file when determining the “line_regex” string.
The table can now be queried using a HeavyDB client as normal:
The previous example uses the default provided “default_local_regex_parsed” server, which can be used to access files on the local file system without having to create a separate server object. Similar default servers exist for the CSV (default_local_delimited) and Parquet (default_local_parquet) data wrappers.
The above example shows how a log file can be queried using the regex parsed file data wrapper. However, in certain cases, log messages may span multiple lines. In such a case, a “line_start_regex” option can be used to indicate the start of a new entry.
Assume that the log file has the following content with some entries spanning multiple lines:
Create a foreign table that extracts all the fields in the logs:
The table can now be queried using a HeavyDB client as normal:
ODBC HeavyConnect is currently in beta.
This example illustrates how the ODBC data wrapper can be used to access data residing in a PostgreSQL RDMS.
/etc/odbc.ini file with the following configuration:Alternatively, the above configuration can be put in an .odbc.ini file in the home directory (i.e. ~/.odbc.ini), if the server process is started under a specific user account.
data_source_name is set to the name that is configured in the ~/.odbc.ini file.
You can now query the foreign table as normal.
For more information, see ODBC Data Wrapper Reference.
ODBC HeavyConnect is currently in beta.
The above example shows how an RDMS can be accessed using an ODBC configuration file that resides in the server. System administrator might not know and configure all possible RDMS databases that users want to use; the ODBC data wrapper provides an alternative of setting the configuration for remote RDMS databases using a connection string.
In this example, assume that data needs to be fetched from another PostgreSQL database called “my_postgres_db”, which is on a server with hostname “my_postgres.example.com” running on port 1234.
/etc/odbcinst.ini file with configurations for all drivers:Use an intuitive name for the driver. Ideally, this should be the official name of the RDMS, so that users can easily figure out the driver name to use when creating the foreign server object.
Users can create foreign server objects using their RDMS database details and name of the installed driver.
When the “connection_string” option is used in the foreign server definition, the corresponding user mapping has to use a “credential_string” option, which contains the username and password.
You can now query the foreign table as normal.
For more information, see ODBC Data Wrapper Reference.