Re[2]: Index-only scan not working when IN clause has 2 or more values - Mailing list pgsql-general
| From | Anna B. |
|---|---|
| Subject | Re[2]: Index-only scan not working when IN clause has 2 or more values |
| Date | |
| Msg-id | 1669640948.115398878@f420.i.mail.ru Whole thread Raw |
| In response to | Re: Index-only scan not working when IN clause has 2 or more values (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-general |
Hi Tom and community,
Thank you very much!
After digging how Postgres planner uses statistics, I have increased table statistics from 100 to 1000. It was enough for planner to use multiple scans of the index and then sort!
(Also I have added dependency extended stats on the three columns as you suggested).
Can I ask one more question. I am also testing same index but covering version:
create index "ix-transaction-client-trans_dttm-include-division"
on transaction (client_id,
trans_dttm desc)
include (division_code);
Why tuned statistics does not improved it?
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
"Index Scan using ""ix-transaction-client-trans_dttm-include-division"" on transaction (cost=0.57..8243559.04 rows=240 width=921) (actual time=23920.988..23920.989 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[]))"
Rows Removed by Filter: 10000000
Buffers: shared hit=8021895 read=2038341
I/O Timings: read=8902.706
Planning Time: 1.278 ms
Execution Time: 23921.026 ms
Yes, I have read about covering indexes in Postgres, about why it has to check rows visibility. But do not understand why Postgres prefers to filter 10000000 table rows instead of filtering in index + using visibility map.
Btw, visibility map is up to date:
relpages, reltuples, relallvisible
23478634, 210520464, 23478634
Thank you in advance,
Dmitry
Пятница, 25 ноября 2022, 18:40 +03:00 от Tom Lane <tgl@sss.pgh.pa.us>:
Anna B. <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=28072 width=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
pgsql-general by date: