On Mon, Feb 20, 2017 at 12:05 PM, Rushabh Lathia
<rushabh.lathia@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