Re: Problem with default partition pruning

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.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-09T14:41:34Z
Lists: pgsql-hackers
On 2019-Aug-09, Amit Langote wrote:

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

Yeah, I was quite confused about this point yesterday while I was trying
to make sense of your patches.

> RelOptInfo.partition_qual is poorly named in retrospect.
> :(  It's not set for all partitions, only those that are partitioned
> themselves.

Oh.  Hmm, I think this realization further clarifies things.

Since we're only changing this in the master branch anyway, maybe we can
find a better name for it.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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.