Re: pgsql: Support partition pruning at execution time - Mailing list pgsql-committers

From David Rowley
Subject Re: pgsql: Support partition pruning at execution time
Date
Msg-id CAKJS1f-FUnvjTqwf_8UvtvhRMeK6DRtS1OKqzPtq+M66aY9Y9g@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Support partition pruning at execution time  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-committers
On 10 April 2018 at 09:58, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> I then noticed that support for nfiltered3 was incomplete; hence 0001.
> (I then noticed that nfiltered3 was added for MERGE.  It looks wrong to
> me.)
>
> Frankly, I don't like this.  I would rather have an instrument->ntuples2
> rather than these "divide this by nloops, sometimes" schizoid counters.
> This is already being misused by ON CONFLICT (see "other_path" in
> show_modifytable_info).  But it seems like a correct fix would require
> more code.

+1 for a new field for this and making ON CONFLICT use it.

ntuples2 seems fine. If we make it too specific then we'll end up with
lots more than we need.

I don't think re-using the filter counters are very good when it's not
for filtering.

MERGE was probably just following the example made by ON CONFLICT.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Support partition pruning at execution time
Next
From: Alexander Korotkov
Date:
Subject: Re: pgsql: Fix behavior of ~> (cube, int) operator