On Mon, Feb 20, 2017 at 12:05 PM, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: > Thanks Amit for raising this point. I was not at all aware of mark/restore. > I tried to come up with the case, but haven't found such case. > > For now here is the patch with comment update.
I think for reproducing this you need plan something like below (I think this is a really bad plan, but you can use to test this particular case). MergeJoin -> Index Scan -> Gather Merge ->Parallel Index Scan So if only IndexScan node is there as a inner node which support Mark/Restore then we don't need to insert any materialize node. But after we put Gather Merge (which don't support Mark/Restore) then we need a materialize node on top of that. Therefore, plan should become like this, I think so. (But anyway if we have the Gather instead of the GatherMerge we would required a Sort node on top of the Gather and Materialize is obviously cheaper than the Sort.) MergeJoin -> Index Scan -> Materialize -> Gather Merge (Does not support mark/restore) ->Parallel Index Scan -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
