Re: pgsql: Support partition pruning at execution time

Andrew Gierth wrote:
> >>>>> "Alvaro" == Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 
>  Alvaro> Thanks for cleaning that up. I'll look into why the test
>  Alvaro> (without this commit) fails with force_parallel_mode=regress
>  Alvaro> next week.
> 
> Seems clear enough to me - the "Heap Fetches" statistic is kept in the
> IndexOnlyScanState node in its own field, not part of ss.ps.instrument,
> and is therefore not reported from workers to leader.

Right, thanks for the pointer.

So here's a patch that makes thing behave as expected.  I noticed that
instrument->nfiltered3 was available, so I used that to keep the
counter.  I wanted to print it using show_instrumentation_count (which
has the nice property that you don't even have to test for es->analyze),
but it doesn't work, because it divides the number by nloops, which is
not what we want in this case.  (It also doesn't print if the counter is
zero, which maybe is desirable for the other counters but probably not
for this one).

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.

Anyway, the partition_prune test works correctly now (after reverting
AndrewSN's b47a86f5008f26) in both force_parallel_mode settings.

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