Re: Runtime pruning problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Yuzuko Hosoya <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Runtime pruning problem
Date: 2019-12-12 00:14:50
Message-ID: 18891.1576109690@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> OK, so here's a finished set of patches for this issue.
> 0001 is the same patch I posted on Tuesday; I kept it separate just
> because it seemed like a largely separable set of changes. (Note that
> the undesirable regression test output changes are undone by 0002.)
> 0002 implements the map-vars-back-to-the-inheritance parent change
> per my sketch. Notice that relation aliases and Var names change
> underneath Appends/MergeAppends, but Vars above one are (mostly)
> printed the same as before. On the whole I think this is a good
> set of test output changes, reflecting a more predictable approach
> to assigning aliases to inheritance children. But somebody else
> might see it differently I suppose.
> Finally, 0003 is the remaining portion of David's patch to allow
> deletion of all of an Append/MergeAppend's sub-plans during
> executor startup pruning.

I pushed these, and the buildfarm immediately got a bad case of
the measles. All the members using force_parallel_mode = regress
fail on the new regression test case added by 0003, with diffs
like this:

diff -U3 /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/partition_prune.out /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/partition_prune.out
--- /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/partition_prune.out Thu Dec 12 00:40:04 2019
+++ /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/partition_prune.out Thu Dec 12 00:45:44 2019
@@ -3169,10 +3169,12 @@
--------------------------------------------
Limit (actual rows=0 loops=1)
Output: ma_test.a, ma_test.b
+ Worker 0: actual rows=0 loops=1
-> Merge Append (actual rows=0 loops=1)
Sort Key: ma_test.b
+ Worker 0: actual rows=0 loops=1
Subplans Removed: 3
-(5 rows)
+(7 rows)

deallocate mt_q2;
reset plan_cache_mode;

This looks to me like there's some other part of EXPLAIN that
needs to be updated for the possibility of zero child nodes, but
I didn't find out just where in a few minutes of searching.

As a stopgap to get back to green buildfarm, I removed this
specific test case, but we need to look at it closer.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tsunakawa.takay@fujitsu.com 2019-12-12 01:04:28 RE: get_database_name() from background worker
Previous Message Alex Adriaanse 2019-12-11 23:49:05 Re: Corruption with duplicate primary key