Re: pgsql: Support partition pruning at execution time

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "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.

BTW, pademelon just exhibited a different instability in this test:

*** /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/partition_prune.out	Sun Apr  8 01:56:04 2018
--- /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/results/partition_prune.out	Sun Apr  8 17:48:14 2018
***************
*** 1606,1612 ****
           ->  Partial Aggregate (actual rows=1 loops=3)
                 ->  Parallel Append (actual rows=0 loops=3)
                       Subplans Removed: 6
!                      ->  Parallel Seq Scan on ab_a2_b1 (actual rows=0 loops=1)
                             Filter: ((a >= $1) AND (a <= $2) AND (b < 4))
                       ->  Parallel Seq Scan on ab_a2_b2 (actual rows=0 loops=1)
                             Filter: ((a >= $1) AND (a <= $2) AND (b < 4))
--- 1606,1612 ----
           ->  Partial Aggregate (actual rows=1 loops=3)
                 ->  Parallel Append (actual rows=0 loops=3)
                       Subplans Removed: 6
!                      ->  Parallel Seq Scan on ab_a2_b1 (actual rows=0 loops=2)
                             Filter: ((a >= $1) AND (a <= $2) AND (b < 4))
                       ->  Parallel Seq Scan on ab_a2_b2 (actual rows=0 loops=1)
                             Filter: ((a >= $1) AND (a <= $2) AND (b < 4))

======================================================================

Dunno quite what to make of that, but this animal previously passed
at commit 
b47a86f Sun Apr 8 05:35:42 2018 UTC  Attempt to stabilize partition_prune test output. 
so it's not a consistent failure.

			regards, tom lane