Matheus Alcantara писал(а) 2025-12-19 16:45:
> On Thu Dec 18, 2025 at 6:56 AM -03, Alexander Pyhalov wrote:
>>> + 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'm not sure that new wait event is needed - for observability I think
>> it's not critical
>> to distinguish Append and MergeAppend when they waited for foreign
>> scans. But also it's perhaps
>> doesn't do any harm to record specific wait event.
>>
> Ok, I think that we can keep this way for now and let's see if a new
> wait event is really needed.
>
>>> 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.
>>
>> Overall I like new Appender node. Splitting code in this way really
>> helps to avoid code duplication.
>> However, some similar code is still needed, because logic of getting
>> new
>> tuples is different.
>>
Hi.
I've looked through updated patch. Tested it (also with our fdw).
Overall looks good.
In execAppend.c there's still reference to as_valid_subplans. Also we
could perhaps use palloc0_array() in some more places, for example, for
for state->asyncrequests and state->asyncresults.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
