Re: pgsql: Support partition pruning at execution time

On 9 April 2018 at 09:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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))
>

Reading code it looks like a bug in choose_next_subplan_for_worker():

The following needs to be changed for this patch:

/* Advance to next plan. */
pstate->pa_next_plan++;

I'll think a bit harder about the best way to fix and submit a patch
for it later.

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