Re: [HACKERS] [PATCH] Push limit to sort through a subquery
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] [PATCH] Push limit to sort through a subquery |
Дата | |
Msg-id | CAA4eK1K9hrRMhAC2A-Ysvik=uqoLi4=DFDjo9xMAdW3NFsXHPQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Push limit to sort through a subquery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] Push limit to sort through a subquery
|
Список | pgsql-hackers |
On Fri, Aug 25, 2017 at 7:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I'm inclined to commit both of these after a little more testing and >> self-review, but let me know if anyone else wants to review first. > > Looking through the first one, I wondered whether we needed to > check for a qual expression on Gather or GatherMerge. It seems like > it would be stupid to put a filter on that node rather than its > children, but I see this in both nodeGather.c and nodeGatherMerge.c: > > /* > * initialize child expressions > */ > gatherstate->ps.qual = > ExecInitQual(node->plan.qual, (PlanState *) gatherstate); > > It doesn't look like the qual is actually used anywhere in either node > type. Am I right in thinking this is dead code? > I also think so. I think this was required in some initial versions of gather node patch where we were thinking of having a single node (instead of what we have now that Gather node and beneath there will be partial scan node) to perform parallel scans. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: