On Thu, Aug 24, 2017 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'd have been okay with changing the entire function if it could still be
> doing all cases the same way. But the exception for merge-append (and
> probably soon other cases) means you still end up with a readability
> problem.
I don't really agree with that. I think it's reasonable to handle the
cases where we are just looking through nodes differently than the
others. Just because we can't conveniently avoid recursing in every
case doesn't mean, to me, that we should recurse even when it's easily
avoidable. I think what we might think about doing is have a node
that loops over Subquery Scan and Result and drills down, and then
handle the rest of the cases either as at present or, perhaps, with a
switch.
On another note, here's a second patch applying on top of my earlier
patch to push down Limit through Gather and Gather Merge. This one
propagates information about sorts performed in parallel workers back
to the leader and adjusts the test case to use a non-temp table again.
This second patch has the nice property of being a fairly good test
that the first patch is actually doing something.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers