On Tue, Dec 5, 2017 at 4:23 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > The hash version of this code is now committed as 5bcf389e. Here is a > patch for discussion that adds some extra tests to join.sql to > exercise rescans of a hash join under a Gather node. It fails on > head, because it loses track of the instrumentation pointer after the > first loop as you described (since the Hash coding is the same is the > Sort coding), so it finishes up with no instrumentation data. If you > move ExecParallelRetrieveInstrumentation() to ExecParallelCleanup() as > you showed in your patch, then it passes. The way I'm asserting that > instrumentation data is making its way back to the leader is by > turning off leader participation and then checking if it knows how > many batches there were.
In a later email in this thread, you asked me to consider this patch for commit, but it doesn't apply. I thought that might be the result of conflicts with Amit's patch which I just committed, but I think that's not the real explanation, because it touches the 'join' regression test, not 'select_parallel'. Well, I thought, I'll just find the place where the SQL should be inserted and stick it in there -- trivial rebase, right? Well, not really, because the context surrounding the lines you've added seems to refer to SQL that I can't find in join.sql or anywhere else in the tree. So my suspicion is that this patch is based on your parallel hash patch set rather than master. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
