Re: Asynchronous Append on postgres_fdw nodes.
От | Etsuro Fujita |
---|---|
Тема | Re: Asynchronous Append on postgres_fdw nodes. |
Дата | |
Msg-id | CAPmGK17JTeGJtKrW_xeRtbXaPBBEQy3+AcOdqcrM0fnHGmJVsw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Asynchronous Append on postgres_fdw nodes. ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>) |
Ответы |
Re: Asynchronous Append on postgres_fdw nodes.
|
Список | pgsql-hackers |
On Tue, Apr 27, 2021 at 3:57 PM Andrey V. Lepikhov <a.lepikhov@postgrespro.ru> wrote: > One more question. Append choose async plans at the stage of the Append > plan creation. > Later, the planner performs some optimizations, such as eliminating > trivial Subquery nodes. So, AsyncAppend is impossible in some > situations, for example: > > (SELECT * FROM f1 WHERE a < 10) > UNION ALL > (SELECT * FROM f2 WHERE a < 10); > > But works for the query: > > SELECT * > FROM (SELECT * FROM f1 UNION ALL SELECT * FROM f2) AS q1 > WHERE a < 10; > > As far as I understand, this is not a hard limit. I think so, but IMO I think this would be an improvement rather than a bug fix. > We can choose async > subplans at the beginning of the execution stage. > For a demo, I prepared the patch (see in attachment). > It solves the problem and passes the regression tests. Thanks for the patch! IIUC, another approach to this would be the patch you proposed before [1]. Right? I didn't have time to look at the patch in [1] for PG14. My apologies for that. Actually, I was planning to return it when the development for PG15 starts. Sorry for the late reply. Best regards, Etsuro Fujita [1] https://www.postgresql.org/message-id/7fe10f95-ac6c-c81d-a9d3-227493eb9055%40postgrespro.ru
В списке pgsql-hackers по дате отправления: