Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>, "Adam, Etienne (Nokia-TECH/Issy Les Moulineaux)" <etienne.adam@nokia.com>,
PostgreSQL Bugs <pgsql-bugs@postgresql.org>, "Duquesne,
Pierre (Nokia-TECH/Issy Les Moulineaux)" <pierre.duquesne@nokia.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-17T09:55:45Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- guc_enable_gather_v1.patch (application/octet-stream) patch v1
- execrescan_gathermerge_v2.patch (application/octet-stream) patch v2
On Thu, Aug 17, 2017 at 10:07 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >>> I believe that between this commit and the test-coverage commit from >>> Andres, this open item is reasonably well addressed. If someone >>> thinks more needs to be done, please specify. Thanks. >> >> How big a deal do we think test coverage is? It looks like >> ExecReScanGatherMerge is identical logic to ExecReScanGather, >> which *is* covered according to coverage.postgresql.org, but >> it wouldn't be too surprising if they diverge in future. >> >> I should think it wouldn't be that expensive to create a test >> case, if you already have test cases that invoke GatherMerge. >> Adding a right join against a VALUES clause with a small number of >> entries, and a non-mergeable/hashable join clause, ought to do it. >> > > > Another way to make it parallel is, add a new guc enable_gather > similar to enable_gathermerge and then set that to off, it will prefer > GatherMerge in that case. I think it is anyway good to have such a > guc. I will go and do it this way unless you have a better idea. > Going by above, I have created two separate patches. First to introduce a new guc enable_gather and second patch to test the rescan behavior of gather merge. I have found a problem in the rescan path of gather merge which is that it is not initializing the gather merge state which is required to initialize the heap for processing of tuples. I think this should have been caught earlier, but probably I didn't notice it because in the previous tests left side would not have passed enough rows to hit this case. I have fixed it in the attached patch (execrescan_gathermerge_v2). > Note - enable_gathermerge is not present in postgresql.conf. I think > we should add it in the postgresql.conf.sample file. > Thomas has already posted a patch to handle this problem. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Separate reinitialization of shared parallel-scan state from ExecReScan.
- d6a149f4e6a1 10.0 landed
- 41b0dd987d44 11.0 landed
-
Restore test case from a2b70c89ca1a5fcf6181d3c777d82e7b83d2de1b.
- 6c2c5bea3cec 11.0 landed
- 5816ddc707e0 10.0 landed
-
Force rescanning of parallel-aware scan nodes below a Gather[Merge].
- 54eac6e8c552 10.0 landed
- 7df2c1f8daeb 11.0 landed
-
Fix ExecReScanGatherMerge.
- de1ca6919ff8 10.0 landed
- a2b70c89ca1a 11.0 landed
-
Add missing call to ExecReScanGatherMerge.
- 29990634c76a 10.0 landed
- 1295a777882b 11.0 landed