Re: pgsql: Support partition pruning at execution time
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: David Rowley <david.rowley@2ndquadrant.com>,
Andrew Gierth <andrew@tao11.riddles.org.uk>,
pgsql-committers@lists.postgresql.org
Date: 2018-04-09T20:55:21Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > David Rowley wrote: >> Okay, I've written and attached a fix for this. I'm not 100% certain >> that this is the cause of the problem on pademelon, but the code does >> look wrong, so needs to be fixed. Hopefully, it'll make pademelon >> happy, if not I'll think a bit harder about what might be causing that >> instability. > Pushed it just now. Let's see what happens with pademelon now. I've had pademelon's host running a "make installcheck" loop all day trying to reproduce the problem. I haven't gotten a bite yet (although at 15+ minutes per cycle, this isn't a huge number of tests). I think we were remarkably (un)lucky to see the problem so quickly after the initial commit, and I'm afraid pademelon isn't going to help us prove much about whether this was the same issue. This does remind me quite a bit though of the ongoing saga with the postgres_fdw test instability. Given the frequency with which that's failing in the buildfarm, you would not think it's impossible to reproduce outside the buildfarm, and yet I'm here to tell you that it's pretty damn hard. I haven't succeeded yet, and that's not for lack of trying. Could there be something about the buildfarm environment that makes these sorts of things more likely? regards, tom lane
Commits
-
Update Append's idea of first_partial_plan
- b7e2cbc5b49f 11.0 landed
-
Fix IndexOnlyScan counter for heap fetches in parallel mode
- 15a8f8caad14 11.0 landed
-
Fix incorrect logic for choosing the next Parallel Append subplan
- 468abb8f7a69 11.0 landed
-
Minor comment updates
- d7a95f06a1a1 11.0 landed
-
Attempt to stabilize partition_prune test output.
- b47a86f5008f 11.0 landed
-
Support partition pruning at execution time
- 499be013de65 11.0 cited