From: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, 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-05-07 10:35:50 |
Message-ID: | 52d944ea-7d41-1d16-01b7-8d1edf5ea972@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/5/21 14:11, Etsuro Fujita wrote:
> On Tue, Apr 27, 2021 at 3:57 PM Andrey V. Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>> 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.
>
> I think so, but IMO I think this would be an improvement rather than a bug fix.
>
>> 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.
>
> Thanks for the patch! IIUC, another approach to this would be the
> patch you proposed before [1]. Right?
Yes. I think, new solution will be better.
--
regards,
Andrey Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2021-05-07 10:41:27 | Re: batch fdw insert bug (Postgres 14) |
Previous Message | Andrey Lepikhov | 2021-05-07 10:32:47 | Re: Asynchronous Append on postgres_fdw nodes. |