Re: Scanning all partition when more than 100 items in "where id in()" clause - Mailing list pgsql-bugs
From | Amit Langote |
---|---|
Subject | Re: Scanning all partition when more than 100 items in "where id in()" clause |
Date | |
Msg-id | 99ac127f-d5b4-961f-08c2-a2da4be701f7@lab.ntt.co.jp Whole thread Raw |
In response to | Re: Scanning all partition when more than 100 items in "where id in()" clause (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
List | pgsql-bugs |
On 2018/07/27 17:57, Amit Langote wrote: > Fwiw, on the tiny machine I work on, attempting pruning with 100-item list > takes way longer than it takes the planner to just forget about pruning > and create a plan for all partitions. But that's just about the planning > time. [ ... ] > -- 101-item list disabling pruning > explain analyze select * from lt where b in > (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, > 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1); > > QUERY PLAN > > > > ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── > ───────────────────────────────────────────────────────────────────────────────────── > Append (cost=0.29..4463.78 rows=51360 width=8) (actual > time=0.172..141.214 rows=10000 loops=1) > -> Index Scan using lt_1_b_idx on lt_1 (cost=0.29..438.78 rows=5136 > width=8) (actual time=0.153..55.516 rows=10000 loops=1) > Index Cond: (b = ANY > ('{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, > 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}'::integer[])) > -> Index Scan using lt_2_b_idx on lt_2 (cost=0.29..442.78 rows=5136 > width=8) (actual time=0.091..0.091 rows=0 loops=1) > Index Cond: (b = ANY > ('{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, > 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}'::integer[])) > -> Index Scan using lt_3_b_idx on lt_3 (cost=0.29..446.78 rows=5136 > width=8) (actual time=0.090..0.090 rows=0 loops=1) > Index Cond: (b = ANY > ('{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, > 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}'::integer[])) > > [ Index Scan nodes of remaining patitions ] > > Planning time: 7.146 ms > Execution time: 184.115 ms > (23 rows) > > Oddly, that seems exactly the opposite of what OP is seeing. When I tried this again, the planning time for the 101-item list case shot up. Not sure what had gone wrong in the previous try. explain analyze select * from lt where b in (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1); QUERY PLAN ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ───────────────────────────────────────────────────────────────────────────────────── Append (cost=0.29..2021.75 rows=10009 width=8) (actual time=0.104..137.582 rows=10000 loops=1) -> Index Scan using lt_1_b_idx on lt_1 (cost=0.29..403.78 rows=10000 width=8) (actual time=0.094..55.329 rows=10000 loops=1) Index Cond: (b = ANY ('{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}'::integer[])) -> Index Scan using lt_2_b_idx on lt_2 (cost=0.29..177.55 rows=1 width=8) (actual time=0.093..0.093 rows=0 loops=1) Index Cond: (b = ANY ('{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}'::integer[])) -> Index Scan using lt_3_b_idx on lt_3 (cost=0.29..173.55 rows=1 width=8) (actual time=0.045..0.045 rows=0 loops=1) Index Cond: (b = ANY ('{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}'::integer[])) [ Index Scan nodes of remaining patitions ] Planning time: 63.100 ms Execution time: 178.995 ms (23 rows) So yes, attempting pruning would've helped the 101-item case just as much as it does the 100-item case. Thanks, Amit
pgsql-bugs by date: