From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Top-N sorts verses parallelism |
Date: | 2017-12-15 20:13:20 |
Message-ID: | CA+Tgmob06kL5+pw3tkK2bgG_fqaBZfMC3QwiDPL0N05DFsj1UQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-12-15 20:36:17 | Re: portal pinning |
Previous Message | Gene Selkov | 2017-12-15 19:49:11 | genomic locus |