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:

Previous
From: Amit Langote
Date:
Subject: Re: Scanning all partition when more than 100 items in "where id in()" clause
Next
From: John Daniel
Date:
Subject: Re: BUG #15300: "do you want the application "postgres" to acceptincoming network connections" dialog box madness