Re: [HACKERS] [PATCH] Push limit to sort through a subquery
От | Konstantin Knizhnik |
---|---|
Тема | Re: [HACKERS] [PATCH] Push limit to sort through a subquery |
Дата | |
Msg-id | 712fe4f7-3707-5147-f73a-31c6a72a54b2@postgrespro.ru обсуждение исходный текст |
Ответ на | [HACKERS] [PATCH] Push limit to sort through a subquery (Douglas Doole <dougdoole@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH] Push limit to sort through a subquery
|
Список | pgsql-hackers |
On 22.08.2017 17:27, Konstantin Knizhnik wrote:
On 18.08.2017 04:33, Robert Haas wrote: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.--
I am not absolutely sure that it is possible to append any query which can be constructed by postgres_fdw for foreign scan with "LIMIT n" clause.
But I also do not know example when it is not possible. As you have mentioned, "FOR UPDATE LIMIT n" is currently recognized by Postgres.
I have inspected deparseSelectStmtForRel function and now I am sure that appending LIMIT to the SQL statement generated by this function will not cause any problems.
It can produce only the following subset of SELECT:
select <target-list> FROM <table-list> [GROUP BY ... [ HAVING ... ]] [ OREDER BY ... ] [ FOR UPDATE ... ];
The only suspicious clause is FOR UPDATE, but I have checked that "FOR UPDATE ... LIMIT n" is really accepted by Postgres parser.
-- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: