Re: Top-N sorts verses parallelism

On Fri, Dec 15, 2017 at 2:10 PM, Jeff Janes <jeff.janes@gmail.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