|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|
|Views:||Raw Message | Whole Thread | Download mbox|
Thanks for the feedback on my original patch Robert. Here's an updated
patch that will tunnel through multiple SubqueryScanStates.
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>
>> 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
|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.|