Ниже приведена оригинальная документация Trino. Скоро мы ее переведем на русский язык и дополним полезными примерами.
The type of distributed join to use. When set to
uses hash distributed joins. When set to
BROADCAST, it broadcasts the
right table to all nodes in the cluster that have data from the left table.
Partitioned joins require redistributing both tables using a hash of the join key.
This can be slower, sometimes substantially, than broadcast joins, but allows much
larger joins. In particular broadcast joins are faster, if the right table is
much smaller than the left. However, broadcast joins require that the tables on the right
side of the join after filtering fit in memory on each node, whereas distributed joins
only need to fit in distributed memory across all nodes. When set to
Trino makes a cost based decision as to which distribution type is optimal.
It considers switching the left and right inputs to the join. In
mode, Trino defaults to hash distributed joins if no cost could be computed, such as if
the tables do not have statistics.
This property enables redistribution of data before writing. This can eliminate the performance impact of data skew when writing by hashing it across nodes in the cluster. It can be disabled, when it is known that the output data set is not skewed, in order to avoid the overhead of hashing and redistributing all the data across the network.
The 351 release of Trino changes the HTTP client protocol headers to start with
X-Trino-. Clients for versions 350 and lower expect the HTTP headers to
X-Presto-, while newer clients expect
X-Trino-. You can support these
older clients by setting this property to
The preferred approach to migrating from versions earlier than 351 is to update all clients together with the release, or immediately afterwards, and then remove usage of this property.
Ensure to use this only as a temporary measure to assist in your migration efforts.
Prepared statements that are submitted to Trino for processing, and are longer than the value of this property, are compressed for transport via the HTTP header to improve handling, and to avoid failures due to hitting HTTP header size limits.
Prepared statement compression is not applied if the size gain is less than the configured value. Smaller statements do not benefit from compression, and are left uncompressed.
Значение по умолчанию:
Включает сбор статистик использования таблиц, отображаемых в системной таблице cedrusdata.stats_table_usage.