Re: [HACKERS] Gather Merge
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] Gather Merge |
Дата | |
Msg-id | CAFiTN-vajTT4fHxo_0b6Sg5KLrgeTQnO2-rfW6L7wVWckb3=_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Gather Merge (Rushabh Lathia <rushabh.lathia@gmail.com>) |
Ответы |
Re: [HACKERS] Gather Merge
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: