| From: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | "Alexander Korotkov" <aekorotkov(at)gmail(dot)com> |
| Cc: | "Alexander Pyhalov" <a(dot)pyhalov(at)postgrespro(dot)ru>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Asynchronous MergeAppend |
| Date: | 2026-04-07 13:52:14 |
| Message-ID: | DHMZ0F9DRKZ4.1LECS9HL5CECX@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon Apr 6, 2026 at 9:19 PM -03, Alexander Korotkov wrote:
>> Minor comment on 0005:
>>
>> +static void
>> +ExecMergeAppendAsyncGetNext(MergeAppendState *node, int mplan)
>> +{
>> + /*
>> + * All initial async requests were fired by ExecAppendBaseAsyncBegin.
>>
>> Wondering if we should reference ExecMergeAppendAsyncBegin() instead of
>> ExecAppendBaseAsyncBegin() since this is on nodeMergeAppend, what do you
>> think?
>
> Technically current comment is correct, because async requests are
> essetially fired by ExecAppendBaseAsyncBegin(). But yes, since we're
> on nodeMergeAppend, it would be less confusing to mention
> ExecMergeAppendAsyncBegin(). Fixed.
>
Thanks for the updated version.
I did another round of review and testing and it looks good to me, I did
not find any issue or strange behaviour.
With the refactor the async support for MergeAppend is not too
complicated. My main concern on this patch series is about the refactor
itself, if we are missing something or changing some behaviour without
notice, however as the async/sync Append execution is also using the
refactored code and we have a good code coveraged I fell a bit confident
that we are right here.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-04-07 13:52:33 | Re: Implement waiting for wal lsn replay: reloaded |
| Previous Message | Andres Freund | 2026-04-07 13:47:26 | Re: pg_buffercache: Add per-relation summary stats |