Re: Problem with default partition pruning

Amit Langote <amitlangote09@gmail.com>

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-09T04:17:41Z
Lists: pgsql-hackers

Attachments

Horiguchi-san,

Thanks for the review.

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.

> Also, I'd like to see comments that the partition_quals is
> already varnode-fixed.

Added a one-line comment.

> And 0002, yeah, just +1 from me.

Thanks.

Attached updated patches; only 0001 changed per above comments.

Regards,
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.