Re: Make Append subplans async capable in more cases

From: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make Append subplans async capable in more cases
Date: 2026-11-03 15:35:07
Message-ID: 0f96ad6b2f16bd77a33f9bbe330c3fa1@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kirill Reshke писал(а) 2026-11-03 18:12:
> On Tue, 3 Nov 2026 at 18:34, Alexander Pyhalov
> <a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
>>
>> While looking at the latest version of the patch, I've asked myself,
>> why
>> consider_async_append decisions are a bit different now for Append and
>> MergeAppend.
>> Perhaps, Append shouldn't completely avoid introducing async foreign
>> scans when it deals with range-partitioned tables?
>>
>>
>>
>> --
>> Best regards,
>> Alexander Pyhalov,
>> Postgres Professional
>
> Hi!
> Is this proposed as a separate patch or should work with other async
> append patches?
>
> in this case
>
> CREATE TABLE ordered_append_remote (a int);
> INSERT INTO ordered_append_remote VALUES (1), (2);
> CREATE TABLE ordered_append_parent (a int) PARTITION BY RANGE (a);
> CREATE FOREIGN TABLE ordered_append_low PARTITION OF
> ordered_append_parent
> FOR VALUES FROM (0) TO (100) SERVER ordered_append_loopback
> OPTIONS (schema_name 'public', table_name 'ordered_append_remote');
> CREATE TABLE ordered_append_high PARTITION OF ordered_append_parent
> FOR VALUES FROM (100) TO (200);
> INSERT INTO ordered_append_high VALUES (101), (102);
> CREATE INDEX ON ordered_append_high (a);
> ANALYZE ordered_append_parent;
>
> SELECT a FROM ordered_append_parent ORDER BY a LIMIT 1;
>
>
> Last select returns 101 rather than 1

Hi. Yes, sorry, this was my error. Async append will not preserve order,
so this attempt is clearly wrong.
--
Best regards,
Alexander Pyhalov,
Postgres Professional

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-11-03 16:02:28 Re: [PATCH] Fix segmentation fault caused by reentrancy in RI_Fkey_cascade_del (ri_triggers.c)
Previous Message Peter Eisentraut 2026-11-03 15:34:36 -Wcast-qual home stretch