Re: pgsql: Support partition pruning at execution time

On 9 April 2018 at 09:54, Tom Lane <tgl@sss.pgh.pa.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