Re: Asynchronous Append on postgres_fdw nodes.
От | Etsuro Fujita |
---|---|
Тема | Re: Asynchronous Append on postgres_fdw nodes. |
Дата | |
Msg-id | CAPmGK16eLyjXSTD7Q+fALtUW175zeO732jFOpEvh+=D5trziFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Asynchronous Append on postgres_fdw nodes. (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Список | pgsql-hackers |
On Tue, May 11, 2021 at 6:55 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Tue, May 11, 2021 at 6:27 PM Andrey Lepikhov > <a.lepikhov@postgrespro.ru> wrote: > > On 11/5/21 12:24, Etsuro Fujita wrote: > > > >> -> Append (actual rows=3000 loops=1) > > >> -> Async Foreign Scan on f1 (actual rows=0 loops=1) > > >> -> Async Foreign Scan on f2 (actual rows=0 loops=1) > > >> -> Foreign Scan on f3 (actual rows=3000 loops=1) > > >> > > >> Here we give preference to the synchronous scan. Why? > > > > > > This would be expected behavior, and the reason is avoid performance > > > degradation; you might think it would be better to execute the async > > > Foreign Scan nodes more aggressively, but it would require > > > waiting/polling for file descriptor events many times, which is > > > expensive and might cause performance degradation. I think there is > > > room for improvement, though. > > Yes, I agree with you. Maybe you can add note in documentation on > > async_capable, for example: > > "... Synchronous and asynchronous scanning strategies can be mixed by > > optimizer in one scan plan of a partitioned table or an 'UNION ALL' > > command. For performance reasons, synchronous scans executes before the > > first of async scan. ..." > > +1 But I think this is an independent issue, so I think it would be > better to address the issue separately. I have committed the patch for the original issue. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: