Re: Asynchronous Append on postgres_fdw nodes.
| От | Andrey V. Lepikhov | 
|---|---|
| Тема | Re: Asynchronous Append on postgres_fdw nodes. | 
| Дата | |
| Msg-id | 3aa386ee-99d7-551f-85cf-c13b78947d4f@postgrespro.ru обсуждение исходный текст  | 
		
| Ответ на | Re: Asynchronous Append on postgres_fdw nodes. (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) | 
| Ответы | 
                	
            		Re: Asynchronous Append on postgres_fdw nodes.
            		
            		 | 
		
| Список | 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.lepikhov@postgrespro.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 'frgn2n.sh' 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
https://postgrespro.com
		
	Вложения
В списке pgsql-hackers по дате отправления: