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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] [PATCH] Push limit to sort through a subquery
Дата
Msg-id CA+Tgmobw5goj6aURp+owc-uwreUAzvyNf_YSwv-zkZ_K=JzQiQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Push limit to sort through a subquery  (Douglas Doole <dougdoole@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Push limit to sort through a subquery  (Douglas Doole <dougdoole@gmail.com>)
Re: [HACKERS] [PATCH] Push limit to sort through a subquery  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
Дерево обсуждения
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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Re: ICU collation variant keywords and pg_collationentries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values)
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: [HACKERS] postgres_fdw bug in 9.6