Fix executor conf link

citusdata · Aug 10, 2021 · aaf3155 · aaf3155
1 parent eaedddf
commit aaf3155
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 1 deletion.
diff --git a/develop/api_guc.rst b/develop/api_guc.rst
@@ -355,6 +355,8 @@ limitations as reference tables (see :ref:`ddl` and :ref:`citus_sql_reference`).
 If you drop the foreign keys, Citus will automatically remove such local tables from metadata,
 which eliminates such limitations on those tables.
 
+.. _executor_configuration:
+
 Executor Configuration
 ------------------------------------------------------------
 

diff --git a/performance/performance_tuning.rst b/performance/performance_tuning.rst
@@ -327,7 +327,7 @@ that have a compact binary representation, such as ``hll``, ``tdigest``,
 Adaptive Executor
 -----------------
 
-Citus' adaptive executor conserves database connections to help reduce resource usage on worker nodes during multi-shard queries. When running a query, the executor begins by using a single -- usually precached -- connection to a remote node. If the query finishes within the time period specified by citus.executor_slow_start_interval, no more connections are required. Otherwise the executor gradually establishes new connections as directed by citus.executor_slow_start_interval. (See also https://docs.citusdata.com/en/latest/develop/api_guc.html#adaptive-executor-configuration)
+Citus' adaptive executor conserves database connections to help reduce resource usage on worker nodes during multi-shard queries. When running a query, the executor begins by using a single -- usually precached -- connection to a remote node. If the query finishes within the time period specified by citus.executor_slow_start_interval, no more connections are required. Otherwise the executor gradually establishes new connections as directed by citus.executor_slow_start_interval. (See also :ref:`executor_configuration`).
 
 With the behavior explained above, the executor aims to open an optimal number of connections to remote nodes. For short running multi-shard queries, like an index-only-scan on the shards, the executor may use only a single connection and execute all the queries on the shards over a single connection. For longer running multi-shard queries, the executor will keep opening connections to parallelize the execution on the remote nodes. If the queries on the shards take long (such as > 500ms), the executor converges to using one connection per shard (or up to citus.max_adaptive_executor_pool_size), in order to maximize the parallelism.