Re: [PATCH] Push limit to sort through a subquery

From: Douglas Doole <dougdoole(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Push limit to sort through a subquery
Date: 2017-08-18 15:42:43
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Thanks for the feedback on my original patch Robert. Here's an updated
patch that will tunnel through multiple SubqueryScanStates.

- Doug

On Thu, Aug 17, 2017 at 6:33 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Aug 17, 2017 at 11:36 AM, Douglas Doole <dougdoole(at)gmail(dot)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:
> The Enterprise PostgreSQL Company

Attachment Content-Type Size
limitSQsort.v2.patch text/x-patch 3.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-18 16:13:39 Re: Proposal : For Auto-Prewarm.
Previous Message Robert Haas 2017-08-18 15:28:18 Re: Quorum commit for multiple synchronous replication.