Re: Top-N sorts verses parallelism

On Fri, Dec 15, 2017 at 2:10 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> I had hit on the same change. And was also surprised that it was located
> where it was. With the change, it uses the parallel plan all the way down
> to LIMIT 1.
>
> With the patch, it still satisfies make check, so if it introduces errors
> they are subtle ones. If we can't actually do this and it needs to stay -1,
> then I think we need a comment to explain why.

Interesting. I suspect this is correct now, but would not have been
before commit 3452dc5240da43e833118484e1e9b4894d04431c. AFAICS, this
doesn't affect any execution-time behavior, just the cost estimate.
And, prior to that commit, the execution-time behavior was different:
there would not have been any way for the worker to do a top-N sort,
because the LIMIT was not pushed through the Gather.

Does that sound right, or am I still confused?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company