Re: why partition pruning doesn't work?

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: why partition pruning doesn't work?
Дата
Msg-id 8d1da0f7-0cfa-307c-ea03-92b618f60c5e@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: why partition pruning doesn't work?  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: why partition pruning doesn't work?  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 2018/06/06 18:52, David Rowley wrote:
> On 6 June 2018 at 18:05, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> On 2018/06/06 14:10, David Rowley wrote:
>>> I then decided that
>>> I didn't like the way we need to check which params are in the Expr
>>> each time we call partkey_datum_from_expr. It seems better to prepare
>>> this in advance when building the pruning steps. I started work on
>>> that, but soon realised that I'd need to pass a List of Bitmapsets to
>>> the executor. This is a problem as Bitmapset is not a Node type and
>>> cannot be copied with COPY_NODE_FIELD(). Probably this could be
>>> refactored to instead of passing 3 Lists in the PartitionPruneStepOp
>>> we could invent a new node type that just has 3 fields and store a
>>> single List.
>>
>> I wonder why we need to create those Bitmapsets in the planner?  Why not
>> in ExecSetupPartitionPruneState()?  For example, like how
>> context->exprstates is initialized.
> 
> That seems like a good idea.  Certainly much better than working them
> out each time we prune.
> 
> v3 patch attached.

Thanks David.  This one looks good.  I also like it that hasparamlessexprs
is no longer determined and set in the planner.

I checked what happens with the cases that Ashutosh complained about
upthread and seems that the pruning works as expected.

create table t1 (a int, b int) partition by range (a);
create table t1p1 partition of t1 for values from (0) to (100);
create table t1p2 partition of t1 for values from (100) to (200);
create index on t1 (a);
insert into t1 select i, i from generate_series(0, 199) i;

explain (costs off, analyze) select * from t1 x left join t1 y on x.a =
y.b + 100 where y.a = 5;
                                          QUERY PLAN

-----------------------------------------------------------------------------------------------
 Nested Loop (actual time=0.294..0.371 rows=1 loops=1)
   ->  Append (actual time=0.067..0.092 rows=1 loops=1)
         ->  Bitmap Heap Scan on t1p1 y (actual time=0.049..0.059 rows=1
loops=1)
               Recheck Cond: (a = 5)
               Heap Blocks: exact=1
               ->  Bitmap Index Scan on t1p1_a_idx (actual
time=0.022..0.022 rows=1 loops=1)
                     Index Cond: (a = 5)
   ->  Append (actual time=0.192..0.219 rows=1 loops=1)
         ->  Index Scan using t1p1_a_idx on t1p1 x (never executed)
               Index Cond: (a = (y.b + 100))
         ->  Index Scan using t1p2_a_idx on t1p2 x_1 (actual
time=0.134..0.145 rows=1 loops=1)
               Index Cond: (a = (y.b + 100))
 Planning Time: 5.314 ms
 Execution Time: 0.938 ms
(14 rows)

Note that the condition x.a = y.b + 100 is able to prune t1p1, whereas on
HEAD it isn't.

Thanks,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: libpq compression
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: commitfest 2018-07