On Mon, Feb 20, 2017 at 1:58 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> 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
>
Yes, exactly that's what will happen, however, we are not sure how
many times such plan (Gather Merge on inner side of merge join) will
be helpful and whether adding Mark/Restore support will make it any
faster than just adding Materialize on top of Gather Merge. So, it
seems better not to go there unless we see some use of it.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
