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
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 |