Re: Asynchronous Append on postgres_fdw nodes.

From: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: etsuro(dot)fujita(at)gmail(dot)com, movead(dot)li(at)highgo(dot)ca, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Date: 2020-06-15 09:59:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 6/15/20 1:29 PM, Kyotaro Horiguchi wrote:
> Thanks for testing, but..
> At Mon, 15 Jun 2020 08:51:23 +0500, "Andrey V. Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru> wrote in
>> The patch has a problem with partitionwise aggregates.
>> Asynchronous append do not allow the planner to use partial
>> aggregates. Example you can see in attachment. I can't understand why:
>> costs of partitionwise join are less.
>> Initial script and explains of the query with and without the patch
>> you can see in attachment.
> I had more or less the same plan with the second one without the patch
> (that is, vanilla master/HEAD, but used merge joins instead).
> I'm not sure what prevented join pushdown, but the difference between
> the two is whether the each partitionwise join is pushed down to
> remote or not, That is hardly seems related to the async execution
> patch.
> Could you tell me how did you get the first plan?

1. Use clear current vanilla master.

2. Start two instances with the script '' from attachment.
There are I set GUCs:
enable_partitionwise_join = true
enable_partitionwise_aggregate = true

3. Execute query:
explain analyze SELECT sum(parts.b)
FROM parts, second
WHERE parts.a = second.a AND second.b < 100;

That's all.

Andrey Lepikhov
Postgres Professional

Attachment Content-Type Size application/x-shellscript 3.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-06-15 09:59:49 Re: Review for GetWALAvailability()
Previous Message Peter Eisentraut 2020-06-15 09:49:53 Re: SEARCH and CYCLE clauses