Этот пример демонстрирует, как преобразование pgpro_planner работает для следующего запроса:

EXPLAIN (COSTS FALSE) SELECT * FROM onek
  WHERE unique1 IN (VALUES(1200), (1));

Без преобразования план выполнения запроса выглядит следующим образом:

Nested Loop
  ->  Unique
        ->  Sort
              Sort Key: "*VALUES*".column1
              ->  Values Scan on "*VALUES*"
  ->  Index Scan using onek_unique1 on onek
        Index Cond: (unique1 = "*VALUES*".column1)
(7 rows)

Для выражения VALUES планировщик создаёт соответствующую временную таблицу и выполняет сравнения значений с помощью узлов Nested Loop и Index Cond. Эти решения приводят к долгому времени выполнения запроса.

Когда pgpro_planner преобразовывает выражение VALUES, результирующий план для того же запроса использует более эффективный узел Bitmap Heap Scan вместо Nested Loop, что сокращает время выполнения запроса.

Bitmap Heap Scan on onek
  Recheck Cond: (unique1 = ANY ('{1200,1}'::integer[]))
  ->  Bitmap Index Scan on onek_unique1
        Index Cond: (unique1 = ANY ('{1200,1}'::integer[]))
(4 rows)

pgpro_planner не может преобразовывать выражения VALUES в следующих случаях:

Этот пример демонстрирует, как арифметическое упрощение pgpro_planner затрагивает планы выполнения для следующего запроса:

SELECT * FROM t WHERE x + 0 > 900;

Для исходной арифметической операции планировщик создаёт план выполнения с узлом Seq Scan и не использует индекс.

Seq Scan on t  (cost=0.00..20.00 rows=333 width=4) (actual time=0.500..0.571 rows=100.00 loops=1)
  Filter: ((x + 0) > 900)
  Rows Removed by Filter: 900
  Buffers: shared hit=5
Planning:
  Buffers: shared hit=14
Planning Time: 0.432 ms
Execution Time: 0.627 ms
(8 rows)

Когда pgpro_planner упрощает такую операцию, планировщик создаёт план с узлом Index Only Scan и выполняет сравнения значений в узле Index Cond, что помогает сократить время выполнения запроса.

Index Only Scan using idx_t_x on t  (cost=0.28..10.03 rows=100 width=4) (actual time=0.077..0.247 rows=100.00 loops=1)
  Index Cond: (x > 900)
  Heap Fetches: 100
  Index Searches: 1
  Buffers: shared hit=4
Planning Time: 0.217 ms
Execution Time: 0.319 ms
(7 rows)

pgpro_planner имеет следующие ограничения для арифметического упрощения:

Этот пример демонстрирует, как работает кеширование связанных подзапросов в разных сценариях.

Создайте две простых таблицы с именами t и t1, а также уникальный индекс по столбцу x первой таблицы.

CREATE TABLE t (x int, y int);
INSERT INTO t SELECT id, id%20 FROM generate_series(1,1000) id;
CREATE UNIQUE INDEX t_x_idx ON t (x);
CREATE TABLE t1 (x1 int);
INSERT INTO  t1 SELECT id%2 FROM generate_series(1,1000) id;

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

EXPLAIN (COSTS OFF)
SELECT x FROM t WHERE (t.x,t.y) = (SELECT sum(x1),1 FROM t1 WHERE x1 = t.y LIMIT 1);
                    QUERY PLAN
------------------------------------------------
  Seq Scan on t
    Filter: (SubPlan 1)
    SubPlan 1
      ->  Memoize
            Cache Key: t.y
            Cache Mode: binary
            ->  Limit
                  ->  Aggregate
                        ->  Seq Scan on t1
                              Filter: (x1 = t.y)
(10 rows)

Запустите другой запрос, в котором подзапрос использует значения из связанного столбца с именем x. Уникальный индекс по этому столбцу существует, но статистическая информация ещё не собрана, поэтому узел Memoize генерируется.

EXPLAIN (COSTS OFF)
SELECT x FROM t WHERE (t.x,t.y) = (SELECT sum(x1),1 FROM t1 WHERE x1 = t.x LIMIT 1);
                    QUERY PLAN
------------------------------------------------
  Seq Scan on t
    Filter: (SubPlan 1)
    SubPlan 1
      ->  Memoize
            Cache Key: t.x
            Cache Mode: binary
            ->  Limit
                  ->  Aggregate
                        ->  Seq Scan on t1
                              Filter: (x1 = t.x)
(10 rows)

Запустите тот же запрос ещё раз. Статистическая информация для столбца x теперь собрана, и уникальный индекс всё ещё существует, поэтому узел Memoize не добавлен в план.

EXPLAIN (COSTS OFF)
SELECT x FROM t WHERE (t.x,t.y) = (SELECT sum(x1),1 FROM t1 WHERE x1 = t.x LIMIT 1);
                            QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on t
   Filter: (x = (SubPlan 1))
   SubPlan 1
     ->  Limit
           ->  Aggregate
                 ->  Seq Scan on t1
                       Filter: (x1 = t.x)
(7 rows)

Удалите ранее созданный индекс и создайте новый составной индекс по обоим столбцам с именами x и y.

CREATE UNIQUE INDEX on t(x,y);
DROP INDEX t_x_idx;

Запустите запрос, ссылающийся на связанный столбец y. Хотя существует составной уникальный индекс, значения этого столбца не уникальны на основе статистической информации. Узел Memoize добавляется в результирующий план.

EXPLAIN (COSTS OFF)
SELECT x FROM t WHERE (t.x,t.y) = (SELECT sum(x1),1 FROM t1 WHERE x1 = t.y LIMIT 1);
                            QUERY PLAN
-----------------------------------------------------------------
  Seq Scan on t
    Filter: (((x = (SubPlan 1).col1) AND (y = (SubPlan 1).col2)))
    SubPlan 1
      ->  Memoize
            Cache Key: t.y
            Cache Mode: binary
            ->  Limit
                  ->  Aggregate
                        ->  Seq Scan on t1
                              Filter: (x1 = t.y)
(10 rows)

Запустите запрос, ссылающийся на связанный столбец x. Для этого случая узел Memoize по-прежнему не генерируется, поскольку значения столбца уникальны на основе статистической информации.

EXPLAIN (COSTS OFF)
SELECT x FROM t WHERE (t.x,t.y) = (SELECT sum(x1),1 FROM t1 WHERE x1 = t.x LIMIT 1);
                            QUERY PLAN
-----------------------------------------------------------------
  Seq Scan on t
    Filter: (((x = (SubPlan 1).col1) AND (y = (SubPlan 1).col2)))
    SubPlan 1
      ->  Limit
            ->  Aggregate
                  ->  Seq Scan on t1
                        Filter: (x1 = t.x)
(7 rows)

pgpro_planner не может кешировать результаты связанного подзапроса в следующих случаях: