Коннектор PostgreSQL#

Коннектор PostgreSQL позволяет запрашивать и создавать таблицы во внешней базе данных PostgreSQL. Его можно использовать для объединения данных между разными системами, например PostgreSQL и Hive, или между разными экземплярами PostgreSQL.

Требования#

Для подключения к PostgreSQL необходимо:

PostgreSQL 12.x или выше.
Сетевой доступ от координатора и workers Trino к PostgreSQL. Порт по умолчанию — 5432.

Конфигурация#

Коннектор может запрашивать базу данных на сервере PostgreSQL. Создайте файл свойств каталога, который указывает коннектор PostgreSQL, задав connector.name равным postgresql.

Например, чтобы обращаться к базе данных как к каталогу example, создайте файл etc/catalog/example.properties. Замените свойства подключения в соответствии с вашей средой:

connector.name=postgresql
connection-url=jdbc:postgresql://example.net:5432/database
connection-user=root
connection-password=secret

connection-url задает сведения о подключении и параметры, передаваемые JDBC-драйверу PostgreSQL. Параметры URL доступны в документации JDBC-драйвера PostgreSQL. Некоторые параметры могут негативно влиять на поведение коннектора или не работать с ним.

connection-user и connection-password обычно обязательны и определяют учетные данные пользователя для подключения, часто сервисного пользователя. Можно использовать секреты, чтобы не хранить реальные значения в файлах свойств каталога.

Доступ к системным таблицам#

Коннектор PostgreSQL поддерживает чтение таблиц каталога PostgreSQL, например pg_namespace. Функциональность по умолчанию отключена и может быть включена с помощью свойства конфигурации postgresql.include-system-tables.

Дополнительные сведения можно посмотреть в схеме pg_catalog каталога example, например о системной таблице pg_namespace:

SHOW TABLES FROM example.pg_catalog;
SELECT * FROM example.pg_catalog.pg_namespace;

Безопасность подключения#

Если на источнике данных настроен TLS с глобально доверенным установленным сертификатом, можно включить TLS между кластером и источником данных, добавив параметр к строке подключения JDBC, заданной в свойстве конфигурации каталога connection-url.

Например, с версией 42 JDBC-драйвера PostgreSQL включите TLS, добавив параметр ssl=true к свойству конфигурации connection-url:

connection-url=jdbc:postgresql://example.net:5432/database?ssl=true

Дополнительные сведения о параметрах конфигурации TLS см. в документации JDBC-драйвера PostgreSQL.

Аутентификация источника данных#

Коннектор может передавать учетные данные для подключения к источнику данных несколькими способами:

непосредственно в файле конфигурации коннектора;
в отдельном файле свойств;
в файле хранилища ключей;
как дополнительные учетные данные, заданные при подключении к Trino.

Можно использовать секреты, чтобы не хранить конфиденциальные значения в файлах свойств каталога.

В следующей таблице описаны свойства конфигурации для учетных данных подключения:

Имя свойства	Описание
`credential-provider.type`	Тип поставщика учетных данных. Должен быть одним из `INLINE`, `FILE` или `KEYSTORE`; по умолчанию — `INLINE`.
`connection-user`	Имя пользователя подключения.
`connection-password`	Пароль подключения.
`user-credential-name`	Имя свойства дополнительных учетных данных, значение которого используется как имя пользователя. См. `extraCredentials` в справочнике параметров.
`password-credential-name`	Имя свойства дополнительных учетных данных, значение которого используется как пароль.
`connection-credential-file`	Расположение файла свойств, в котором находятся учетные данные. Он должен содержать свойства `connection-user` и `connection-password`.
`keystore-file-path`	Расположение файла Java Keystore, из которого считываются учетные данные.
`keystore-type`	Формат файла хранилища ключей, например `JKS` или `PEM`.
`keystore-password`	Пароль для хранилища ключей.
`keystore-user-credential-name`	Имя сущности хранилища ключей, используемой как имя пользователя.
`keystore-user-credential-password`	Пароль для сущности хранилища ключей с именем пользователя.
`keystore-password-credential-name`	Имя сущности хранилища ключей, используемой как пароль.
`keystore-password-credential-password`	Пароль для сущности хранилища ключей с паролем.

Несколько баз данных или серверов PostgreSQL#

Коннектор PostgreSQL может обращаться только к одной базе данных внутри сервера PostgreSQL. Поэтому, если у вас несколько баз данных PostgreSQL или нужно подключиться к нескольким серверам PostgreSQL, необходимо настроить несколько экземпляров коннектора PostgreSQL.

Чтобы добавить еще один каталог, просто добавьте еще один файл свойств в etc/catalog с другим именем, убедившись, что оно заканчивается на .properties. Например, если назвать файл свойств sales.properties, Trino создаст каталог sales с использованием настроенного коннектора.

Общие свойства конфигурации#

В следующей таблице описаны общие свойства конфигурации каталога для коннектора:

Имя свойства	Описание
`case-insensitive-name-matching`	Поддержка имен схем и таблиц без учета регистра. По умолчанию — `false`.
`case-insensitive-name-matching.cache-ttl`	Длительность, в течение которой кэшируются имена схем и таблиц при сопоставлении без учета регистра. По умолчанию — `1m`.
`case-insensitive-name-matching.config-file`	Путь к конфигурационному файлу сопоставления имен в формате JSON, который позволяет Trino различать схемы и таблицы с похожими именами в разных регистрах. По умолчанию — `null`.
`case-insensitive-name-matching.config-file.refresh-period`	Частота, с которой Trino проверяет конфигурационный файл сопоставления имен на изменения. Значение длительности по умолчанию — `0s` (обновление отключено).
`metadata.cache-ttl`	Длительность, в течение которой кэшируются метаданные, включая статистику таблиц и столбцов. По умолчанию — `0s` (кэширование отключено).
`metadata.cache-missing`	Кэшировать факт недоступности метаданных, включая статистику таблиц и столбцов. По умолчанию — `false`.
`metadata.schemas.cache-ttl`	Длительность, в течение которой кэшируются метаданные схем. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.tables.cache-ttl`	Длительность, в течение которой кэшируются метаданные таблиц. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.statistics.cache-ttl`	Длительность, в течение которой кэшируется статистика таблиц. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.cache-maximum-size`	Максимальное число объектов, хранящихся в кэше метаданных. По умолчанию — `10000`.
`write.batch-size`	Максимальное число операторов в пакетном выполнении. Не меняйте это значение относительно значения по умолчанию. Нестандартные значения могут отрицательно повлиять на производительность. По умолчанию — `1000`.
`dynamic-filtering.enabled`	Проталкивать динамические фильтры в JDBC-запросы. По умолчанию — `true`.
`dynamic-filtering.wait-timeout`	Максимальная длительность, в течение которой Trino ожидает сбора динамических фильтров со стороны построения соединения перед запуском JDBC-запроса. Большой тайм-аут потенциально может дать более подробные динамические фильтры, но также может увеличить задержку некоторых запросов. По умолчанию — `20s`.

Добавление метаданных запроса#

Необязательный параметр query.comment-format позволяет настроить SQL-комментарий, который отправляется источнику данных с каждым запросом. Формат комментария может содержать любые символы и следующие метаданные:

$QUERY_ID: идентификатор запроса.
$USER: имя пользователя, отправившего запрос в Trino.
$SOURCE: идентификатор клиентского инструмента, использованного для отправки запроса, например trino-cli.
$TRACE_TOKEN: токен трассировки, настроенный в клиентском инструменте.

Комментарий может предоставить больше контекста о запросе. Эта дополнительная информация доступна в журналах источника данных. Чтобы включить в комментарий переменные окружения из кластера Trino, используйте синтаксис ${ENV:VARIABLE-NAME}.

Следующий пример задает простой комментарий, идентифицирующий каждый запрос, отправленный Trino:

query.comment-format=Query sent by Trino.

С такой конфигурацией запрос вроде SELECT * FROM example_table; отправляется источнику данных с добавленным комментарием:

SELECT * FROM example_table; /*Query sent by Trino.*/

Следующий пример улучшает предыдущий, используя метаданные:

query.comment-format=Query $QUERY_ID sent by user $USER from Trino.

Если Jane отправила запрос с идентификатором 20230622_180528_00000_bkizg, источнику данных отправляется следующая строка комментария:

SELECT * FROM example_table; /*Query 20230622_180528_00000_bkizg sent by user Jane from Trino.*/

Note

Некоторые настройки драйвера JDBC и конфигурации журналирования могут привести к удалению комментария.

Порог компактирования домена#

Проталкивание большого списка предикатов в источник данных может ухудшить производительность. По умолчанию Trino компактирует большие предикаты в более простой предикат диапазона, чтобы сохранить баланс между производительностью и проталкиванием предикатов. При необходимости порог такого компактирования можно увеличить, чтобы повысить производительность, когда источник данных способен эффективно использовать большие предикаты. Увеличение этого порога может улучшить проталкивание больших динамических фильтров. Свойство конфигурации каталога domain-compaction-threshold или свойство сеанса каталога domain_compaction_threshold можно использовать для изменения значения по умолчанию 256 для этого порога.

Сопоставление без учета регистра#

Когда case-insensitive-name-matching установлено в true, Trino может запрашивать схемы и таблицы с именами не только в нижнем регистре, поддерживая сопоставление имени в нижнем регистре с фактическим именем в удаленной системе. Однако если две схемы и/или таблицы имеют имена, различающиеся только регистром, например “customers” и “Customers”, Trino не сможет запрашивать их из-за неоднозначности.

В таких случаях используйте свойство конфигурации каталога case-insensitive-name-matching.config-file, чтобы указать конфигурационный файл, сопоставляющий эти удаленные схемы и таблицы с соответствующими схемами и таблицами Trino. Кроме того, JSON-файл должен включать оба свойства, schemas и tables, даже если они заданы только как пустые массивы.

{
  "schemas": [
    {
      "remoteSchema": "CaseSensitiveName",
      "mapping": "case_insensitive_1"
    },
    {
      "remoteSchema": "cASEsENSITIVEnAME",
      "mapping": "case_insensitive_2"
    }],
  "tables": [
    {
      "remoteSchema": "CaseSensitiveName",
      "remoteTable": "tablex",
      "mapping": "table_1"
    },
    {
      "remoteSchema": "CaseSensitiveName",
      "remoteTable": "TABLEX",
      "mapping": "table_2"
    }]
}

Запросы к одной из таблиц или схем, заданных в атрибутах mapping, выполняются к соответствующей удаленной сущности. Например, запрос к таблицам в схеме case_insensitive_1 перенаправляется в схему CaseSensitiveName, а запрос к case_insensitive_2 — в схему cASEsENSITIVEnAME.

На уровне сопоставления таблиц запрос к case_insensitive_1.table_1 в приведенной выше конфигурации перенаправляется к CaseSensitiveName.tablex, а запрос к case_insensitive_1.table_2 — к CaseSensitiveName.TABLEX.

По умолчанию после изменения конфигурационного файла сопоставления Trino нужно перезапустить, чтобы загрузить изменения. При необходимости можно задать case-insensitive-name-matching.config-file.refresh-period, чтобы Trino обновлял свойства без перезапуска:

case-insensitive-name-matching.config-file.refresh-period=30s

Поддержка отказоустойчивого выполнения#

Коннектор поддерживает Fault-tolerant execution для обработки запросов. Операции чтения и записи поддерживаются с любой политикой повторных попыток.

Сопоставление типов#

Поскольку Trino и PostgreSQL поддерживают типы, которых нет в другой системе, этот коннектор изменяет некоторые типы при чтении или записи данных. Типы данных могут сопоставляться по-разному в направлениях между Trino и источником данных. В следующих разделах описано сопоставление типов для каждого направления.

Сопоставление типов PostgreSQL с типами Trino#

Коннектор сопоставляет типы PostgreSQL с соответствующими типами Trino согласно следующей таблице:

Сопоставление типов PostgreSQL с типами Trino#
Тип PostgreSQL	Тип Trino	Примечания
`BIT`	`BOOLEAN`
`BOOLEAN`	`BOOLEAN`
`SMALLINT`	`SMALLINT`
`INTEGER`	`INTEGER`
`BIGINT`	`BIGINT`
`REAL`	`REAL`
`DOUBLE`	`DOUBLE`
`NUMERIC(p, s)`	`DECIMAL(p, s)`	`DECIMAL(p, s)` является псевдонимом `NUMERIC(p, s)`. Дополнительные сведения см. в Decimal type handling.
`CHAR(n)`	`CHAR(n)`
`VARCHAR(n)`	`VARCHAR(n)`
`ENUM`	`VARCHAR`
`BYTEA`	`VARBINARY`
`DATE`	`DATE`
`TIME(n)`	`TIME(n)`
`TIMESTAMP(n)`	`TIMESTAMP(n)`
`TIMESTAMPTZ(n)`	`TIMESTAMP(n) WITH TIME ZONE`
`MONEY`	`VARCHAR`
`UUID`	`UUID`
`JSON`	`JSON`
`JSONB`	`JSON`
`VECTOR`	`ARRAY(REAL)`
`HSTORE`	`MAP(VARCHAR, VARCHAR)`
`ARRAY`	Отключено, `ARRAY` или `JSON`	Дополнительные сведения см. в Обработка типа Array.
`GEOMETRY`, `GEOMETRY(GEOMETRY TYPE, SRID)`	`GEOMETRY`

Другие типы не поддерживаются.

Сопоставление типов Trino с типами PostgreSQL#

Коннектор сопоставляет типы Trino с соответствующими типами PostgreSQL согласно следующей таблице:

Сопоставление типов Trino с типами PostgreSQL#
Тип Trino	Тип PostgreSQL	Примечания
`BOOLEAN`	`BOOLEAN`
`SMALLINT`	`SMALLINT`
`TINYINT`	`SMALLINT`
`INTEGER`	`INTEGER`
`BIGINT`	`BIGINT`
`DOUBLE`	`DOUBLE`
`DECIMAL(p, s)`	`NUMERIC(p, s)`	`DECIMAL(p, s)` является псевдонимом `NUMERIC(p, s)`. Дополнительные сведения см. в Decimal type handling.
`CHAR(n)`	`CHAR(n)`
`VARCHAR(n)`	`VARCHAR(n)`
`VARBINARY`	`BYTEA`
`DATE`	`DATE`
`TIME(n)`	`TIME(n)`
`TIMESTAMP(n)`	`TIMESTAMP(n)`
`TIMESTAMP(n) WITH TIME ZONE`	`TIMESTAMPTZ(n)`
`UUID`	`UUID`
`JSON`	`JSONB`
`ARRAY`	`ARRAY`	Дополнительные сведения см. в Обработка типа Array.
`GEOMETRY`	`GEOMETRY`

Другие типы не поддерживаются.

Decimal type handling#

DECIMAL types with unspecified precision or scale are ignored unless the decimal-mapping configuration property or the decimal_mapping session property is set to allow_overflow. Then such types are mapped to a Trino DECIMAL with a default precision of 38 and default scale of 0. To change the scale of the resulting type, use the decimal-default-scale configuration property or the decimal_default_scale session property. The precision is always 38.

By default, values that require rounding or truncation to fit will cause a failure at runtime. This behavior is controlled via the decimal-rounding-mode configuration property or the decimal_rounding_mode session property, which can be set to UNNECESSARY (the default), UP, DOWN, CEILING, FLOOR, HALF_UP, HALF_DOWN, or HALF_EVEN (see RoundingMode).

Обработка типа Array#

Реализация массивов PostgreSQL не поддерживает фиксированные размерности, тогда как Trino поддерживает только массивы с фиксированными размерностями. Можно настроить, как коннектор PostgreSQL обрабатывает массивы, с помощью свойства конфигурации postgresql.array-mapping в файле каталога или свойства сеанса array_mapping. Для этого свойства принимаются следующие значения:

DISABLED (по умолчанию): столбцы массивов пропускаются.
AS_ARRAY: столбцы массивов интерпретируются как тип Trino ARRAY для столбцов массивов с фиксированными размерностями.
AS_JSON: столбцы массивов интерпретируются как тип Trino JSON без ограничения на размерности.

Свойства конфигурации сопоставления типов#

Следующие свойства можно использовать для настройки того, как типы данных из подключенного источника данных сопоставляются с типами данных Trino и как метаданные кэшируются в Trino.

Имя свойства

Описание

Значение по умолчанию

unsupported-type-handling

Настраивает обработку неподдерживаемых типов данных столбцов:

IGNORE — столбец недоступен.
CONVERT_TO_VARCHAR — столбец преобразуется в неограниченный VARCHAR.

Соответствующее свойство сеанса каталога — unsupported_type_handling.

IGNORE

jdbc-types-mapped-to-varchar

Позволяет принудительно сопоставлять списки типов данных, разделенные запятыми, с неограниченным VARCHAR.

Запросы к PostgreSQL#

Коннектор PostgreSQL предоставляет схему для каждой схемы PostgreSQL. Доступные схемы PostgreSQL можно просмотреть, выполнив SHOW SCHEMAS:

SHOW SCHEMAS FROM example;

Если у вас есть схема PostgreSQL с именем web, можно просмотреть таблицы в этой схеме, выполнив SHOW TABLES:

SHOW TABLES FROM example.web;

Список столбцов таблицы clicks в базе данных web можно просмотреть одним из следующих способов:

DESCRIBE example.web.clicks;
SHOW COLUMNS FROM example.web.clicks;

Наконец, можно обратиться к таблице clicks в схеме web:

SELECT * FROM example.web.clicks;

Если вы использовали другое имя для файла свойств каталога, используйте это имя каталога вместо example в приведенных выше примерах.

Поддержка SQL#

Коннектор предоставляет доступ на чтение и запись к данным и метаданным в PostgreSQL. Помимо глобально доступных операторов и операторов чтения, коннектор поддерживает следующие возможности:

INSERT, см. также Нетранзакционный INSERT
UPDATE, см. также Ограничение UPDATE
DELETE, см. также Ограничение DELETE
MERGE, см. также Нетранзакционный MERGE
TRUNCATE
Управление схемами и таблицами, см. также:
- ALTER TABLE RENAME TO limitation
- ALTER SCHEMA limitation
Процедуры
Табличные функции

Нетранзакционный INSERT#

Коннектор поддерживает добавление строк с помощью операторов INSERT. По умолчанию вставка данных выполняется путем записи данных во временную таблицу. Этот шаг можно пропустить, чтобы повысить производительность и писать напрямую в целевую таблицу. Установите свойство каталога insert.non-transactional-insert.enabled или соответствующее свойство сеанса каталога non_transactional_insert в true.

Обратите внимание: при включенном свойстве данные могут быть повреждены в редких случаях, когда во время операции вставки возникают исключения. При отключенных транзакциях откат выполнить невозможно.

Ограничение UPDATE#

Поддерживаются только операторы UPDATE с константными присваиваниями и предикатами. Например, следующий оператор поддерживается, потому что присваиваемые значения являются константами:

UPDATE table SET col1 = 1 WHERE col3 = 1

Арифметические выражения, вызовы функций и другие неконстантные операторы UPDATE не поддерживаются. Например, следующий оператор не поддерживается, поскольку арифметические выражения нельзя использовать с командой SET:

UPDATE table SET col1 = col2 + 2 WHERE col3 = 1

Все значения столбцов строки таблицы нельзя обновить одновременно. Для таблицы из трех столбцов следующий оператор не поддерживается:

UPDATE table SET col1 = 1, col2 = 2, col3 = 3 WHERE col3 = 1

Ограничение DELETE#

Если указано предложение WHERE, операция DELETE работает только в том случае, если предикат в предложении может быть полностью протолкнут в источник данных.

Нетранзакционный MERGE#

Коннектор поддерживает добавление, обновление и удаление строк с помощью операторов MERGE, если свойство каталога merge.non-transactional-merge.enabled или соответствующее свойство сеанса каталога non_transactional_merge_enabled установлено в true. Merge поддерживается только для непосредственного изменения целевых таблиц.

В редких случаях во время операции merge могут возникать исключения, что потенциально приводит к частичному обновлению.

ALTER TABLE RENAME TO limitation#

The connector does not support renaming tables across multiple schemas. For example, the following statement is supported:

ALTER TABLE example.schema_one.table_one RENAME TO example.schema_one.table_two

The following statement attempts to rename a table across schemas, and therefore is not supported:

ALTER TABLE example.schema_one.table_one RENAME TO example.schema_two.table_two

ALTER SCHEMA limitation#

The connector supports renaming a schema with the ALTER SCHEMA RENAME statement. ALTER SCHEMA SET AUTHORIZATION is not supported.

Процедуры#

`system.flush_metadata_cache()`#

Очищает кэши метаданных JDBC. Например, следующий системный вызов очищает кэши метаданных для всех схем в каталоге example:

USE example.example_schema;
CALL system.flush_metadata_cache();

`system.execute('query')`#

Процедура execute позволяет выполнить запрос напрямую в базовом источнике данных. Запрос должен использовать поддерживаемый синтаксис подключенного источника данных. Используйте процедуру для доступа к возможностям, которые недоступны в Trino, или для выполнения запросов, которые не возвращают набор результатов и поэтому не могут использоваться с транзитной табличной функцией query или raw_query. Типичные случаи применения — операторы, создающие или изменяющие объекты и требующие нативных возможностей, таких как ограничения, значения по умолчанию, автоматическое создание идентификаторов или индексы. Запросы также могут вызывать операторы, которые вставляют, обновляют или удаляют данные и не возвращают данных в результате.

Текст запроса не разбирается Trino, а только передается дальше, поэтому он подчиняется только правилам безопасности и контроля доступа базового источника данных.

В следующем примере текущая база данных устанавливается в example_schema каталога example. Затем в этой схеме вызывается процедура, чтобы удалить значение по умолчанию из your_column в таблице your_table с помощью стандартного SQL-синтаксиса в значении параметра query:

USE example.example_schema;
CALL system.execute(query => 'ALTER TABLE your_table ALTER COLUMN your_column DROP DEFAULT');

Убедитесь, что конкретная база данных поддерживает этот синтаксис, и при необходимости адаптируйте его на основе документации конкретной подключенной базы данных и ее версии.

Табличные функции#

Коннектор предоставляет специальные табличные функции для доступа к PostgreSQL.

`query(varchar) -> table`#

Функция query позволяет напрямую запрашивать базовую базу данных. Она требует синтаксис, родной для PostgreSQL, поскольку весь запрос проталкивается вниз и обрабатывается в PostgreSQL. Это может быть полезно для доступа к нативным возможностям, недоступным в Trino, или для повышения производительности запросов в ситуациях, когда выполнение запроса нативно может быть быстрее.

Нативный запрос, переданный базовому источнику данных, должен возвращать таблицу как набор результатов. Проверку и контроль безопасности для таких запросов выполняет только источник данных, используя собственную конфигурацию. Trino не выполняет эти задачи. Используйте транзитные запросы только для чтения данных.

Как простой пример, запросите каталог example и выберите всю таблицу:

SELECT
  *
FROM
  TABLE(
    example.system.query(
      query => 'SELECT
        *
      FROM
        tpch.nation'
    )
  );

Как практический пример, можно использовать frame exclusion из PostgreSQL при использовании оконных функций:

SELECT
  *
FROM
  TABLE(
    example.system.query(
      query => 'SELECT
        *,
        array_agg(week) OVER (
          ORDER BY
            week
          ROWS
            BETWEEN 2 PRECEDING
            AND 2 FOLLOWING
            EXCLUDE GROUP
        ) AS week,
        array_agg(week) OVER (
          ORDER BY
            day
          ROWS
            BETWEEN 2 PRECEDING
            AND 2 FOLLOWING
            EXCLUDE GROUP
        ) AS all
      FROM
        test.time_data'
    )
  );

Note

Движок запросов не сохраняет порядок результатов этой функции. Если переданный запрос содержит предложение ORDER BY, результат функции может быть упорядочен не так, как ожидается.

Производительность#

Коннектор включает ряд улучшений производительности, подробно описанных в следующих разделах.

Статистика таблиц#

Коннектор PostgreSQL может использовать статистику таблиц и столбцов для оптимизаций на основе стоимости, чтобы повышать производительность обработки запросов на основе фактических данных в источнике данных.

Статистика собирается PostgreSQL и извлекается коннектором.

Чтобы собрать статистику для таблицы, выполните следующий оператор в PostgreSQL.

ANALYZE table_schema.table_name;

Дополнительные параметры ANALYZE см. в документации PostgreSQL.

Pushdown#

Коннектор поддерживает pushdown для ряда операций:

Aggregate pushdown для следующих функций:

Note

Коннектор выполняет проталкивание там, где это может повысить производительность, но ради сохранения корректности операция может не проталкиваться. Когда проталкивание операции может дать лучшую производительность, но создает риск для корректности, коннектор отдает приоритет корректности.

Проталкивание соединений на основе стоимости#

Коннектор поддерживает проталкивание соединений на основе стоимости, чтобы принимать обоснованные решения о том, нужно ли проталкивать операцию соединения в источник данных.

Когда проталкивание соединений на основе стоимости включено, коннектор проталкивает операции соединения только если доступная Статистика таблиц указывает, что это повышает производительность. Обратите внимание: если статистика таблиц недоступна, проталкивание операции соединения не выполняется, чтобы избежать потенциального снижения производительности запроса.

В следующей таблице описаны свойства конфигурации каталога для проталкивания соединений:

Имя свойства	Описание	Значение по умолчанию
`join-pushdown.enabled`	Включает проталкивание соединений. Эквивалентное свойство сеанса каталога — `join_pushdown_enabled`.	`true`
`join-pushdown.strategy`	Стратегия, используемая для оценки того, следует ли проталкивать операции соединения. Установите `AUTOMATIC`, чтобы включить проталкивание соединений на основе стоимости, или `EAGER`, чтобы проталкивать соединения всегда, когда это возможно. Обратите внимание, что `EAGER` может проталкивать соединения даже при отсутствии статистики таблиц, что может привести к ухудшению производительности запросов. Поэтому `EAGER` рекомендуется только для тестирования и диагностики.	`AUTOMATIC`

Поддержка predicate pushdown#

Предикаты проталкиваются для большинства типов, включая UUID и временные типы, такие как DATE.

Коннектор не поддерживает pushdown диапазонных предикатов, таких как >, < или BETWEEN, для столбцов с символьными строковыми типами, такими как CHAR или VARCHAR. Предикаты равенства, такие как IN или =, и предикаты неравенства, такие как !=, для столбцов с текстовыми типами проталкиваются. Это обеспечивает корректность результатов, поскольку удаленный источник данных может сортировать строки иначе, чем Trino.

В следующем примере предикат первого запроса не проталкивается, поскольку name — столбец типа VARCHAR, а > — диапазонный предикат. Остальные запросы проталкиваются.

-- Не проталкивается
SELECT * FROM nation WHERE name > 'CANADA';
-- Проталкивается
SELECT * FROM nation WHERE name != 'CANADA';
SELECT * FROM nation WHERE name = 'CANADA';

Существует экспериментальная поддержка включения pushdown диапазонных предикатов для столбцов с символьными строковыми типами; ее можно включить, установив свойство конфигурации каталога postgresql.experimental.enable-string-pushdown-with-collate или соответствующее свойство сеанса enable_string_pushdown_with_collate в true. Включение этой конфигурации приведет к pushdown предиката всех запросов в приведенном выше примере.

Коннектор PostgreSQL#

Требования#

Конфигурация#

Доступ к системным таблицам#

Безопасность подключения#

Аутентификация источника данных#

Несколько баз данных или серверов PostgreSQL#

Общие свойства конфигурации#

Добавление метаданных запроса#

Порог компактирования домена#

Сопоставление без учета регистра#

Поддержка отказоустойчивого выполнения#

Сопоставление типов#

Сопоставление типов PostgreSQL с типами Trino#

Сопоставление типов Trino с типами PostgreSQL#

Decimal type handling#

Обработка типа Array#

Свойства конфигурации сопоставления типов#

Запросы к PostgreSQL#

Поддержка SQL#

Нетранзакционный INSERT#

Ограничение UPDATE#

Ограничение DELETE#

Нетранзакционный MERGE#

ALTER TABLE RENAME TO limitation#

ALTER SCHEMA limitation#

Процедуры#

system.flush_metadata_cache()#

system.execute('query')#

Табличные функции#

query(varchar) -> table#

Производительность#

Статистика таблиц#

Pushdown#

Проталкивание соединений на основе стоимости#

Поддержка predicate pushdown#

`system.flush_metadata_cache()`#

`system.execute('query')`#

`query(varchar) -> table`#