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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Douglas Doole <dougdoole(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 01:33:32
Message-ID: CA+Tgmobw5goj6aURp+owc-uwreUAzvyNf_YSwv-zkZ_K=JzQiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2017-08-18 02:44:18 Re: postgres_fdw bug in 9.6
Previous Message Peter Geoghegan 2017-08-18 01:22:32 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values