Re: Asynchronous Append on postgres_fdw nodes.

Поиск
Список
Период
Сортировка
От Andrey V. Lepikhov
Тема Re: Asynchronous Append on postgres_fdw nodes.
Дата
Msg-id 30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Asynchronous Append on postgres_fdw nodes.  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Ответы Re: Asynchronous Append on postgres_fdw nodes.  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Список pgsql-hackers
On 4/23/21 8:12 AM, Etsuro Fujita wrote:
> I have committed the patch.
While studying the capabilities of AsyncAppend, I noticed an 
inconsistency with the cost model of the optimizer:

async_capable = off:
--------------------
Append  (cost=100.00..695.00 ...)
    ->  Foreign Scan on f1 part_1  (cost=100.00..213.31 ...)
    ->  Foreign Scan on f2 part_2  (cost=100.00..216.07 ...)
    ->  Foreign Scan on f3 part_3  (cost=100.00..215.62 ...)

async_capable = on:
-------------------
Append  (cost=100.00..695.00 ...)
    ->  Async Foreign Scan on f1 part_1  (cost=100.00..213.31 ...)
    ->  Async Foreign Scan on f2 part_2  (cost=100.00..216.07 ...)
    ->  Async Foreign Scan on f3 part_3  (cost=100.00..215.62 ...)


Here I see two problems:
1. Cost of an AsyncAppend is the same as cost of an Append. But 
execution time of the AsyncAppend for three remote partitions has more 
than halved.
2. Cost of an AsyncAppend looks as a sum of the child ForeignScan costs.

I haven't ideas why it may be a problem right now. But I can imagine 
that it may be a problem in future if we have alternative paths: complex 
pushdown in synchronous mode (a few rows to return) or simple 
asynchronous append with a large set of rows to return.

-- 
regards,
Andrey Lepikhov
Postgres Professional



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

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: GISTSTATE is too large
Следующее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Truncate in synchronous logical replication failed