Індекс не використовується з `= any ()`, але використовується з `in`

Таблиця tмає два індекси:

create table t (a int, b int);
create type int_pair as (a int, b int);
create index t_row_idx on t (((a,b)::int_pair));
create index t_a_b_idx on t (a,b);

insert into t (a,b)
select i, i
from generate_series(1, 100000) g(i)
;

Індекс не використовується з anyоператором:

explain analyze
select *
from t
where (a,b) = any(array[(1,1),(1,2)])
;
                                            QUERY PLAN                                             
---------------------------------------------------------------------------------------------------
 Seq Scan on t  (cost=0.00..1693.00 rows=1000 width=8) (actual time=0.042..126.789 rows=1 loops=1)
   Filter: (ROW(a, b) = ANY (ARRAY[ROW(1, 1), ROW(1, 2)]))
   Rows Removed by Filter: 99999
 Planning time: 0.122 ms
 Execution time: 126.836 ms

Але одна з них використовується разом із inоператором:

explain analyze
select *
from t
where (a,b) in ((1,1),(1,2))
;
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Index Only Scan using t_a_b_idx on t  (cost=0.29..8.32 rows=1 width=8) (actual time=0.028..0.029 rows=1 loops=1)
   Index Cond: (a = 1)
   Filter: ((b = 1) OR (b = 2))
   Heap Fetches: 1
 Planning time: 0.161 ms
 Execution time: 0.066 ms

Він використовує індекс запису, якщо запис приведено до правильного типу:

explain analyze
select *
from t
where (a,b)::int_pair = any(array[row(1,1),row(1,2)])
;
                                                  QUERY PLAN                                                  
--------------------------------------------------------------------------------------------------------------
 Index Scan using t_row_idx on t  (cost=0.42..12.87 rows=2 width=8) (actual time=0.106..0.126 rows=1 loops=1)
   Index Cond: (ROW(a, b)::int_pair = ANY (ARRAY[ROW(1, 1), ROW(1, 2)]))
 Planning time: 0.208 ms
 Execution time: 0.203 ms

Чому планувальник не використовує індекс без запису для anyоператора, як він використовує його для inоператора?

Всередині є дві окремі форми з IN, а також для ANYконструкції.

Один з них, беручи набір , еквівалентний іншому і expr IN (<set>)також веде до того ж плану запитів, expr = ANY(<set>)що може використовувати звичайний індекс. Деталі:

• IN vs БУДЬ-ЯКІЙ оператор у PostgreSQL

Отже, наступні два запити еквівалентні, і обидва можуть використовувати простий індекс t_a_b_idx(що також може бути рішенням, якщо ви намагаєтесь отримати ваш запит для використання індексу):

EXPLAIN ANALYZE
SELECT *
FROM t
WHERE (a,b) = ANY(VALUES (1,1),(1,2));

Або:

...
WHERE (a,b) IN (VALUES (1,1),(1,2));

Ідентичне для обох:

                                                        QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.33..16.71 rows=1 width=8) (actual time=0.101..0.101 rows=0 loops=1)
   ->  Unique  (cost=0.04..0.05 rows=2 width=8) (actual time=0.068..0.070 rows=2 loops=1)
         ->  Sort  (cost=0.04..0.04 rows=2 width=8) (actual time=0.067..0.068 rows=2 loops=1)
               Sort Key: "*VALUES*".column1, "*VALUES*".column2
               Sort Method: quicksort  Memory: 25kB
               ->  Values Scan on "*VALUES*"  (cost=0.00..0.03 rows=2 width=8) (actual time=0.005..0.005 rows=2 loops=1)
   ->  Index Only Scan using t_plain_idx on t  (cost=0.29..8.32 rows=1 width=8) (actual time=0.009..0.009 rows=0 loops=2)
         Index Cond: ((a = "*VALUES*".column1) AND (b = "*VALUES*".column2))
         Heap Fetches: 0
 Planning time: 4.080 ms
 Execution time: 0.202 ms

Однак це неможливо легко передати функції, оскільки у Postgres немає "табличних змінних". Що призводить до проблеми, яка розпочала цю тему:

• Передайте функції численні множини або масиви значень

Для цієї проблеми існують різні шляхи вирішення. Один з альтернативних відповідей я додав туди. Деякі інші:

• Вставте значення із змінної запису в таблицю
• Оголосити змінну типу таблиці в PL / pgSQL

Друга форма кожного відрізняється: ANYприймає фактичний масив , тоді як INприймає список значень, розділених комами .

Це має різні наслідки для набору тексту . Як ми бачимо у EXPLAINвисновку питання, така форма:

WHERE (a,b) = ANY(ARRAY[(1,1),(1,2)]);

розглядається як скорочення для:

ROW(a, b) = ANY (ARRAY[ROW(1, 1), ROW(1, 2)])

І фактичні значення ROW порівнюються Наразі Postgres недостатньо розумний, щоб побачити, що індекс для складеного типу t_row_idxзастосовний. Також не усвідомлюється, що простий індекс також t_a_b_idxповинен бути застосований.

Явний акторський склад допомагає подолати цей недолік:

WHERE (a,b)::int_pair = ANY(ARRAY[(1,1),(1,2)]::int_pair[]);

Кастинг правого операнда ( ::int_pair[]) необов’язковий (хоча кращий для продуктивності та уникнення неясностей). Після того, як лівий операнд має добре відомий тип, правий операнд переводиться з "анонімного запису" на відповідний тип. Тільки тоді оператор визначається однозначно. І Postgres вибирає застосовні індекси на основі оператора та лівого операнду. Для багатьох операторів, які визначають a COMMUTATOR, планувальник запитів може перевертати операнди, щоб повернути індексований вираз зліва. Але це неможливо з ANYконструкцією.

Пов'язані:

• Чи є спосіб корисно індексувати текстовий стовпець, що містить шаблони регулярних виразів?

  WHERE (a,b) IN ((1,1),(1,2));

.. Значення приймаються як елементи, і Postgres здатний порівняти окремі цілі значення, як ми можемо побачити у EXPLAINвисновку ще раз:

Filter: ((b = 1) OR (b = 2))

Отже, Postgres виявляє, що простий індекс t_a_b_idxможна використовувати.

Отже, у конкретному випадку у прикладі може бути інше рішення : оскільки власний складовий тип int_pairу прикладі є еквівалентним типу рядка самої таблиці t, ми можемо спростити:

CREATE INDEX t_row_idx2 ON t ((t));

Тоді цей запит використовує індекс без більш явного кастингу:

EXPLAIN ANALYZE
SELECT *
FROM   t
WHERE  t = ANY(ARRAY[(1,1),(1,2)]);

                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on t  (cost=40.59..496.08 rows=1000 width=8) (actual time=0.19
1..0.191 rows=0 loops=1)
   Recheck Cond: (t.* = ANY (ARRAY[ROW(1, 1), ROW(1, 2)]))
   ->  Bitmap Index Scan on t_row_idx2  (cost=0.00..40.34 rows=1000 width=0) (actual time=0.188..0.188 rows=0 loops=1)
         Index Cond: (t.* = ANY (ARRAY[ROW(1, 1), ROW(1, 2)]))
 Planning time: 2.575 ms
 Execution time: 0.267 ms

Але типові випадки використання не зможуть використовувати неявно існуючий тип рядка таблиці.