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: Alvaro Herrera <alvherre@2ndquadrant.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-14T01:12:22Z
Lists: pgsql-hackers 
On Wed, Aug 14, 2019 at 12:25 AM Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> On 2019-Aug-13, Amit Langote wrote:
>
> > Thanks a lot for revising.  Looks neat, except:
> >
> > +     * This is a measure of last resort only to be used because the default
> > +     * partition cannot be pruned using the steps; regular pruning, which is
> > +     * cheaper, is sufficient when no default partition exists.
> >
> > This text appears to imply that the default can *never* be pruned with
> > steps.  Maybe, the first sentence should read something like: "...the
> > default cannot be pruned using the steps generated from clauses that
> > contradict the parent's partition constraint".
>
> Thanks!  I have pushed it with this change.

Thank you Alvaro.  This takes care of all the issues around default
partition pruning reported on this thread.  Thanks everyone.

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.