Horton

Re: Problem with default partition pruning

Amit Langote <amitlangote09@gmail.com>

View thread View on postgr.es
From: Amit Langote <amitlangote09@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, yuzuko <yuzukohosoya@gmail.com>, shawn wang <shawn.wang.pg@gmail.com>, Shawn Wang <shawn.wang@highgo.ca>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-08-09T05:02:36Z
Lists: pgsql-hackers

Attachments

On Fri, Aug 9, 2019 at 1:17 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > > When working on it, I realized
> > > that the way RelOptInfo.partition_qual is processed is a bit
> > > duplicative, so I created a separate patch to make that a bit more
> > > consistent.
> >
> > 0001 seems reasonable. By the way, the patch doesn't touch
> > get_relation_constraints(), but I suppose it can use the modified
> > partition constraint qual already stored in rel->partition_qual
> > in set_relation_partition_info. And we could move constifying to
> > set_rlation_partition_info?
>
> Ah, good advice.  This make partition constraint usage within the
> planner quite a bit more consistent.

Hmm, oops.  I think that judgement was a bit too rushed on my part.  I
unintentionally ended up making the partition constraint to *always*
be fetched, whereas we don't need it in most cases.  I've reverted
that change.  RelOptInfo.partition_qual is poorly named in retrospect.
:(  It's not set for all partitions, only those that are partitioned
themselves.

Attached updated patches.

Thanks,
Amit

Commits

  1. Don't constraint-exclude partitioned tables as much

  2. Apply constraint exclusion more generally in partitioning

  3. Improve pruning of a default partition

  4. Doc: Fix event trigger firing table

  5. Remove obsolete nbtree insertion comment.