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-27 06:57:30 |
Message-ID: | c9388cb7-8cfc-bc92-0d6a-b519e6099cb6@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:
> On Thu, Apr 22, 2021 at 12:30 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> I have committed the patch.
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. 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.
--
regards,
Andrey Lepikhov
Postgres Professional
Attachment | Content-Type | Size |
---|---|---|
asyncappend_executor_fix.patch | text/x-patch | 8.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-04-27 07:25:01 | Re: [BUG] "FailedAssertion" reported when streaming in logical replication |
Previous Message | Amul Sul | 2021-04-27 06:52:20 | Re: Skip temporary table schema name from explain-verbose output. |