Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Aug 24, 2017 at 2:24 PM, Tom Lane <t...@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.
Basically, this argument is that we should contort the code in order
to avoid tail recursion, rather than assuming the compiler will turn
that recursion into iteration, even in cases where there is really
zero evidence that we should be worrying about performance at all
rather than correctness and readability. I do not agree (and just
finished pushing a patch to change it).
> On another note, here's a second patch applying on top of my earlier
> patch to push down Limit through Gather and Gather Merge.
Can you demonstrate any case where the planner would put Gather between
Sort and Limit? The GatherMerge case is probably interesting, but I'm
having doubts about Gather.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
