Starburst PostgreSQL connector#
The Starburst PostgreSQL connector is an extended version of the PostgreSQL connector with configuration and usage identical.
The following improvements are included:
Fulfill the PostgreSQL connector requirements.
Additional features of the connector require a valid Starburst Enterprise license, unless otherwise noted.
The connector supports all of the SQL statements listed in the PostgreSQL connector documentation.
The connector includes a number of performance improvements, detailed in the following sections.
This feature is available for free, and does not require a valid license.
The PostgreSQL connector supports table and column statistics to improve query processing performance based on the actual data in the data source.
The statistics are collected by PostgreSQL and retrieved by the connector.
To collect statistics for a table, execute the following statement in PostgreSQL.
Refer to PostgreSQL documentation for additional
Cost-based join pushdown#
The connector supports cost-based Join pushdown to make intelligent decisions about whether to push down a join operation to the data source.
When cost-based join pushdown is enabled, the connector only pushes down join operations if the available Table statistics suggest that doing so improves performance. Note that if no table statistics are available, join operation pushdown does not occur to avoid a potential decrease in query performance.
The following table describes catalog configuration properties for join pushdown:
Strategy used to evaluate whether join operations are pushed down. Set to
Dynamic filtering is enabled by default. It causes the connector to wait for dynamic filtering to complete before starting a JDBC query.
You can disable dynamic filtering by setting the property
dynamic-filtering.enabled in your catalog properties file to
Starburst Cached Views#
The connectors supports table scan redirection to improve performance and reduce load on the data source.
The connector includes a number of security-related features, detailed in the following sections.
The PostgreSQL connector supports user impersonation.
User impersonation can be enabled in the catalog file:
User impersonation in PostgreSQL connector is based on
For more details visit: www.postgresql.org/docs.
The PostgreSQL connector supports Kerberos-based authentication with the following configuration:
postgresql.authentication.type=KERBEROS firstname.lastname@example.org kerberos.client.keytab=etc/kerberos/example.keytab kerberos.config=etc/kerberos/krb5.conf
With this configuration the user
email@example.com, defined in the
principal property, is used to connect to the database, and the related Kerberos
service ticket is located in the
Kerberos credential pass-through#
The PostgreSQL connector can be configured to pass through Kerberos credentials, received by SEP, to the PostgreSQL database.
Configure Kerberos and SEP, following the instructions in Kerberos credential pass-through.
Then configure the connector to pass through the credentials from the server to the database in your catalog properties file and ensure the Kerberos client configuration properties are in place on all nodes.
postgresql.authentication.type=KERBEROS_PASS_THROUGH http.authentication.krb5.config=/etc/krb5.conf http-server.authentication.krb5.service-name=exampleServiceName http-server.authentication.krb5.keytab=/path/to/Keytab/File
Now any database access via SEP is subject to the data access restrictions and permissions of the user supplied via Kerberos.
Password credential pass-through#
The connector supports password credential pass-through. To enable it, edit the catalog properties file to include the authentication type:
For more information about configurations and limitations, see Password credential pass-through.
AWS IAM authentication#
When the PostgreSQL database is deployed as an AWS RDS instance, the connector can use IAM authentication. This enhancement allows you to manage access control from SEP with IAM policies.
To enable IAM authentication, add the following configuration properties to the catalog configuration file:
postgresql.authentication.type=AWS connection-user=<RDS username> aws.region-name=<AWS region> aws.token-expiration-timeout=10m
You can also configure the connector to assume a specific IAM role for authentication before creating the access token, in order to apply policies specific to SEP. Alongside this role, you must include an (informal) external identifier of a user to assume this role.
To apply an IAM role to the connector, add the following configuration properties:
This table describes the configuration properties for IAM authentication:
The database account used to access the RDS database instance.
The name of the AWS region in which the RDS instance is deployed.
(Optional) Set an IAM role to assume for authentication before creating
the access token. If set,
(Optional) The informal identifier of the user who assumes
the IAM role set in
The amount of time to keep the generated RDS access tokens for each user
before they are regenerated. The maximum value is 15 minutes. Defaults to
The access key of the principal to authenticate with for the token generator service. Used for fixed authentication, setting this property disables automatic authentication.
The secret key of the principal to authenticate with for the token generator service. Used for fixed authentication, setting this property disables automatic authentication.
(Optional) A session token for temporary credentials, such as credentials obtained from SSO. Used for fixed authentication, setting this property disables automatic authentication.
By default the connector attempts to automatically obtain its authentication credentials from the environment. The default credential provider chain attempts to obtain credentials from the following sources, in order:
Java system properties:
Web identity token: credentials from the environment or container.
Credential profiles file: a profiles file at the default location (
~/.aws/credentials) shared by all AWS SDKs and the AWS CLI.
EC2 service credentials: credentials delivered through the Amazon EC2 container service, assuming the security manager has permission to access the value of the
Instance profile credentials: credentials delievered through the Amazon EC2 metadata service.
If the SEP cluster is running on an EC2 instance, these credentials most likely come from the metadata service.
Alternatively, you can set fixed credentials for authentication. This option disables the container’s automatic attempt to locate credentials. To use fixed credentials for authentication, set the following configuration properties:
aws.access-key=<access_key> aws.secret-key=<secret_key> # (Optional) You can use temporary credentials. For example, you can use temporary credentials from SSO aws.session-token=<session_token>