Re: why partition pruning doesn't work? - Mailing list pgsql-hackers

From David Rowley
Subject Re: why partition pruning doesn't work?
Date
Msg-id CAKJS1f_jatg5+qbrha2fGog63t3VdbNnOkYZitJtx-uo5H5EsQ@mail.gmail.com
Whole thread Raw
In response to Re: why partition pruning doesn't work?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: why partition pruning doesn't work?
Re: why partition pruning doesn't work?
List pgsql-hackers
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.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: Sergey Cherkashin
Date:
Subject: processSQLNamePattern() analog