=?UTF-8?B?QW5uYSBCLg==?= <terzi@bk.ru> writes:
> create index "ix-transaction-client-trans_dttm-division"
> on transaction (client_id,
> trans_dttm desc,
> division_code);
>
> EXPLAIN (ANALYZE, BUFFERS)
> select *
> from transaction
> where client_id = 123456
> and (trans_dttm between TO_DATE('01.01.2020', 'dd.mm.yyyy') and TO_DATE('31.12.2022', 'dd.mm.yyyy'))
> and (division_code in
> ('not_existing_code1', 'not_existing_code2'))
> order by trans_dttm desc
> limit 50 offset 0;
The reason you get a plan like this:
> " -> Index Scan using ""ix-transaction-client-trans_dttm-division"" on transaction (cost=0.57..8350814.66
rows=28072width=2675) (actual time=703291.834..703291.835 rows=0 loops=1)"
> " Index Cond: ((client_id = '123456'::numeric) AND (trans_dttm >= to_date('01.01.2020'::text,
'dd.mm.yyyy'::text))AND (trans_dttm <= to_date('31.12.2022'::text, 'dd.mm.yyyy'::text)))"
> " Filter: ((division_code)::text = ANY ('{not_existing_code1,not_existing_code2}'::text[]))"
is that if the =ANY clause were an index condition, it would result
in multiple scans of the index, therefore the output would (in all
probability) not be sorted in index order. To produce the demanded
result, the plan would have to read the entire index scan and sort
its output. The planner estimates that that would be slower than
what it has done here. In practice it looks like you're reading
the whole scan output anyway because there are less than 50
matching rows, but the planner didn't know that.
The problem with =ANY producing unordered output can be dodged if
the =ANY is on the first index column; but I suppose that does not
help you here, since making division_code the first index column
would defeat getting output that's sorted by trans_dttm anyway.
You might try making extended stats on these three columns to see
if that helps the planner to get a better rowcount estimate.
If it understood that there were fewer than 50 matching rows,
it might opt for the use-the-=ANY-and-sort plan type.
regards, tom lane
