From 1ff5a53801d8ef7fc7bec9dabc1d1c1e6c3429f7 Mon Sep 17 00:00:00 2001 From: Marco Slot Date: Mon, 25 Sep 2023 12:25:20 +0200 Subject: [PATCH] Add adaptive executor diagram --- src/backend/distributed/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/distributed/README.md b/src/backend/distributed/README.md index e404b08f9..2db8fb700 100644 --- a/src/backend/distributed/README.md +++ b/src/backend/distributed/README.md @@ -1617,7 +1617,7 @@ Historically, Citus executed single shard queries via a single connection per wo To fulfill the first two requirements, the adaptive executor uses a (process-local) **pool of connections per node**, which typically starts at 1 connection, but can grow based on the runtime of the query. Queries on shard groups that were already modified are assigned to the connection that performed the modification(s), while remaining queries are assigned to the pool (to be parallelized at will). -Adaptive executor pools +Adaptive executor pools **Both the pool and the session have a “pending queue” and a “ready queue”**. The pending queue is mainly used in case of replication (e.g. reference tables). In the case of reads, whether a (pending) task on placement 2 needs to run depends on whether the (ready) task on placement 1 succeeds. In case of inserts, we write to the placements in order, so the task on placement 2 runs only once placement 1 is done.