Re: [PATCH] Push limit to sort through a subquery
Douglas Doole <dougdoole@gmail.com>
From: Douglas Doole <dougdoole@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-08-18T15:42:43Z
Lists: pgsql-hackers
Attachments
- limitSQsort.v2.patch (text/x-patch) patch v2
Thanks for the feedback on my original patch Robert. Here's an updated patch that will tunnel through multiple SubqueryScanStates. - Doug Salesforce On Thu, Aug 17, 2017 at 6:33 PM Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Aug 17, 2017 at 11:36 AM, Douglas Doole <dougdoole@gmail.com> > wrote: > >> I completely agree. The further a limit can be pushed down, the better. >> >> The patch looks good to me. >> > > It seems like a somewhat ad-hoc approach; it supposes that we can take any > query produced by deparseSelectStmtForRel() and stick a LIMIT clause onto > the very end and all will be well. Maybe that's not a problematic > assumption, not sure. The grammar happens to allow both FOR UPDATE LIMIT n > and LIMIT n FOR UPDATE even though only the latter syntax is documented. > > Regarding the other patch on this thread, you mentioned upthread that "If > it is possible to get more than one SubqueryScanState and/or ResultState > between the limit and sort, then the first block of code could be placed in > a while loop." I think that's not possible for a ResultState, but I think > it *is* possible for a SubqueryScanState. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Commits
-
Propagate sort instrumentation from workers back to leader.
- bf11e7ee2e36 11.0 landed
-
Push tuple limits through Gather and Gather Merge.
- 3452dc5240da 11.0 landed
-
Code review for pushing LIMIT through subqueries.
- 3f4c7917b3bc 11.0 landed
-
Make new regression test case parallel-safe, and improve its output.
- 1177ab1dabf7 11.0 landed
-
Push limit through subqueries to underlying sort, where possible.
- 1f6d515a67ec 11.0 landed
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 cited