| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
| 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:12:17 |
| Message-ID: | CALdSSPiaBg3W3k032bC05uVj7sOAEmxX07+knHuYPBEGeDimOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
--
Best regards,
Kirill Reshke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Raja Sai pranav | 2026-11-03 15:17:41 | Re: Re: Offline data checksum changes can cause incorrect checksum state on standbys |
| Previous Message | Greg Burd | 2026-11-03 15:09:00 | Re: Hash index inserts serialise on the metapage tuple counter |