Re: Asynchronous MergeAppend

From: "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>
To: "Alexander Pyhalov" <a(dot)pyhalov(at)postgrespro(dot)ru>, "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>
Cc: "Alena Rybakina" <a(dot)rybakina(at)postgrespro(dot)ru>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Asynchronous MergeAppend
Date: 2025-12-17 20:01:31
Message-ID: DF0RCOYB19RC.35BW2FHPO4N4S@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the new version. I don't have other comments on the current
state of the patch. It seems to working as expected and we have
performance improvements that I think that it make it worthwhile.

I have just a small comment on 0002:

+ noccurred = WaitEventSetWait(node->ms_eventset, -1 /* no timeout */ , occurred_event,
+ nevents, WAIT_EVENT_APPEND_READY);

Should we use the same WAIT_EVENT_APPEND_READY or create a new wait
event for merge append?

I've spent some time thinking about how we could remove some parts of
the duplicated code that you've previously mention. I think that we
could try to create something like we already have for relation scan
operations, that we have execScan.c that is used for example by
nodeSeqScan.c and nodeIndexScan.c. The attached patch 0003 is a draft
that I attempt to implement this idea. The 0001 and 0002 remains the
same as the previous version. The 0003 was build on top of these.

I've created Appender and AppenderState types that are used by
Append/MergeAppend and AppendState/MergeAppendState respectively (I
should have think in a better name for these base type, ideas are
welcome). The execAppend.c was created to have the functions that can be
reused by Append and MergeAppend execution. I've tried to remove
duplicated code blocks that was almost the same and that didn't require
much refactoring.

I think that there still more opportunities to remove similar code
blocks that for example are on ExecMergeAppendAsyncGetNext and
ExecAppendAsyncGetNext but it require refactoring.

Thoughts?

--
Matheus Alcantara
EDB: http://www.enterprisedb.com

Attachment Content-Type Size
v9-0001-mark_async_capable-subpath-should-match-subplan.patch text/plain 2.4 KB
v9-0002-MergeAppend-should-support-Async-Foreign-Scan-sub.patch text/plain 50.3 KB
v9-0003-Create-execAppend.c-to-avoid-duplicated-code-on-M.patch text/plain 85.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-12-17 20:05:50 Re: Visibility bug in tuple lock
Previous Message Tomas Vondra 2025-12-17 19:54:04 Re: index prefetching