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
