From: | "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Asynchronous Append on postgres_fdw nodes. |
Date: | 2021-04-26 06:01:12 |
Message-ID: | 30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | osumi.takamichi@fujitsu.com | 2021-04-26 06:16:43 | RE: Truncate in synchronous logical replication failed |
Previous Message | Andrey Borodin | 2021-04-26 05:11:13 | Re: GISTSTATE is too large |