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

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

  1. Propagate sort instrumentation from workers back to leader.

  2. Push tuple limits through Gather and Gather Merge.

  3. Code review for pushing LIMIT through subqueries.

  4. Make new regression test case parallel-safe, and improve its output.

  5. Push limit through subqueries to underlying sort, where possible.

  6. Move targetlist SRF handling from expression evaluation to new executor node.