Эффективность выполнения запросов в распределённой СУБД определяется тем, сколько операций можно выполнить на узлах, содержащих фактические данные. В Shardman много усилий посвящено тому, чтобы выталкивать операции соединения. Когда планировщик находит отношение, доступное через обёртку сторонних данных (FDW), он создаёт ForeignPath для доступа к нему. Позже, когда он контролирует соединение двух отношений, и оба они доступны через ForeignPath с одного и того же стороннего сервера, он может рассматривать возможность передачи этого соединения на сервер и создания так называемого ForeignJoinPath. Планировщик не может этого сделать, если тип соединения не поддерживается, если фильтры, прикреплённые к отношению, должны применяться локально или если результат сканирования отношения содержит поля, которые невозможно оценить на удалённом сервере. Примером неподдерживаемого в настоящее время типа соединения является антисоединение. Локальные фильтры, прикреплённые к отношению, следует применять локально, если удалённое выполнение может привести к другому результату или если модуль postgres_fdw не может создать SQL-выражения для применения некоторых фильтров. Примером полей, которые нельзя оценить на удалённом сервере, являются атрибуты внутреннего отношения полусоединения, недоступные через внешнее отношение. Если параметр конфигурации foreign_join_fast_path включён (это значение по умолчанию), планировщик Shardman прекращает поиск других стратегий соединения двух отношения, как только он находит возможным для них стороннее соединение. Если параметр конфигурации postgres_fdw.enforce_foreign_join включён (что также является значением по умолчанию), стоимость стороннего соединения оценивается таким образом, чтобы всегда быть меньше стоимости локального соединения.

Когда несколько сегментированных таблиц соединяются по ключу сегментирования, возможно посекционное соединение. Это означает, что вместо соединения исходных таблиц можно соединить их соответствующие секции. В настоящее время посекционное соединение применяется только в том случае, если условия соединения включают все ключи секций, которые должны иметь один и тот же тип данных и иметь точно совпадающие наборы дочерних секций. Посекционное соединение имеет решающее значение для эффективного выполнения запросов, поскольку оно позволяет выталкивать соединения секций таблицы. Очевидно, что для соединения нескольких секций эти секции должны находиться на одном узле. Обычно это происходит, когда сегментированные таблицы создаются с одним и тем же параметром num_parts. Однако, чтобы в процессе перебалансировки соответствующие секции были перемещены на одни и те же узлы, сегментированные таблицы должны быть при создании помечены как совмещённые (см. Подраздел 7.1.1). Посекционное соединение включается параметром enable_partitionwise_join, который в Shardman по умолчанию включён.

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

После планирования соединений планировщик рассматривает пути для операций после соединения, таких как агрегирование, ограничение, сортировка и группировка. Не все такие операции достигают логики выталкивания FDW. Например, в настоящее время секционирование эффективно предотвращает выталкивание предложений LIMIT. Существует две эффективные стратегии выполнения агрегатных функций на удалённых узлах. Первый — это агрегирование по секциям, когда предложение GROUP BY включает ключ секционирования, агрегатная функция может быть вытолкнуто вместе с предложением GROUP BY (это поведение контролируется параметром enable_partitionwise_aggregate, который по умолчанию включён в Shardman). В качестве альтернативы планировщик может решить выполнять частичное агрегирование для каждой секции сегментированной таблицы, а затем соединить результаты. В Shardman такое частичное агрегирование может быть пропущено, если оно соответствует основному агрегированию. Например, неполная функция sum() всегда может быть вытолкнута, а avg() — нет. Также планировщик отказывается выталкивать частичные агрегирования наружу, если они содержат дополнительные предложения, такие как ORDER BY или DISTINCT, или если оператор содержит предложение HAVING.

Как правило, подзапросы нельзя передавать на другие узлы кластера. Однако Shardman использует два подхода для снятия этого ограничения.

Первый — это распаковка подзапросов. В PostgreSQL несвязанные подзапросы могут быть преобразованы в полусоединения. В следующем примере подзапрос ANY к несекционированным таблицам преобразуется в Hash Semi Join:

EXPLAIN (COSTS OFF) SELECT * FROM pgbench_branches WHERE bid = ANY (SELECT bid FROM pgbench_tellers);
                        QUERY PLAN                         
-----------------------------------------------------------
 Hash Semi Join
   Hash Cond: (pgbench_branches.bid = pgbench_tellers.bid)
   ->  Seq Scan on pgbench_branches
   ->  Hash
         ->  Seq Scan on pgbench_tellers

Когда параметр optimize_correlated_subqueries включён (по умолчанию), планировщик Shardman также пытается преобразовывать связанные подзапросы (т. е. подзапросы, которые ссылаются на отношения верхнего уровня) в полусоединения. Эта оптимизация работает для операторов IN и =. Преобразование имеет некоторые ограничения. Например, оно не выполняется, если подзапрос содержит агрегатные функции или ссылается на отношения верхнего уровня вне предложения WHERE. Эта оптимизация позволяет преобразовывать более сложные подзапросы в полусоединения, как в следующем примере:

EXPLAIN (COSTS OFF) SELECT * FROM pgbench_branches WHERE bid = ANY (SELECT bid FROM pgbench_tellers WHERE tbalance = bbalance);
                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Hash Semi Join
   Hash Cond: ((pgbench_branches.bid = pgbench_tellers.bid) AND (pgbench_branches.bbalance = pgbench_tellers.tbalance))
   ->  Seq Scan on pgbench_branches
   ->  Hash
         ->  Seq Scan on pgbench_tellers
(5 rows)

После применения распаковки подзапросов полусоединение можно вынести для выполнения на удалённый узел.

Второй подход заключается в выталкивании всего подзапроса. Это возможно, когда оптимизатор уже выяснил, что подзапрос ссылается только на секции того же стороннего сервера, что и запрос верхнего уровня, и соответствующие сторонние сканирования не имеют локальных условий. Оптимизация контролируется параметром postgres_fdw.subplan_pushdown (по умолчанию отключено). Когда postgres_fdw принимает решение отправить подзапрос, он должен восстановить этот подзапрос. Подзапрос, содержащий узлы плана, для которых не реализовано восстановление, не будет вытолкнут. Пример выталкивания подзапроса выглядит следующим образом:

EXPLAIN (VERBOSE ON, COSTS OFF)
SELECT * FROM pgbench_accounts a WHERE a.bid=90 AND abalance =
    (SELECT min(tbalance) FROM pgbench_tellers t WHERE t.bid=90 and a.bid=t.bid);
                                     QUERY PLAN                                                                                                                   
--------------------------------------------------------------------------------------
 Foreign Scan on public.pgbench_accounts_5_fdw a
   Output: a.aid, a.bid, a.abalance, a.filler
   Remote SQL: SELECT aid, bid, abalance, filler FROM public.pgbench_accounts_5 r2 WHERE ((r2.bid = 90)) AND ((r2.abalance = ((SELECT min(sp0_2.tbalance) FROM public.pgbench_tellers_5 sp0_2 WHERE ((sp0_2.bid = 90)) AND ((r2.bid = 90))))))
   Transport: Silk
   SubPlan 1
     ->  Finalize Aggregate
           Output: min(t.tbalance)
           ->  Foreign Scan
                 Output: (PARTIAL min(t.tbalance))
                 Relations: Aggregate on (public.pgbench_tellers_5_fdw t)
                 Remote SQL: SELECT min(tbalance) FROM public.pgbench_tellers_5 WHERE ((bid = 90)) AND (($1::integer = 90))
                 Transport: Silk

Обратите внимание, что в приведённом выше плане нет ссылок на SubPlan 1.