Re: why partition pruning doesn't work?

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: why partition pruning doesn't work?
Date: 2018-06-06 06:05:51
Message-ID: e6e751ea-0db4-0e7b-9513-97460edb60b3@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajkumar Raghuwanshi 2018-06-06 06:33:30 Re: Test patch for partitionwise join with partitioned tables containing default partition
Previous Message Ashutosh Bapat 2018-06-06 06:02:13 Re: Test patch for partitionwise join with partitioned tables containing default partition