On Mon, Oct 5, 2026 at 6:10 PM Etsuro Fujita <[email protected]> wrote: > On Mon, Oct 5, 2026 at 2:36 AM Alexander Korotkov <[email protected]> > wrote: > > Are you still going to review this patch?
> I'm planning to > provide my initial comments by the end of next week, hopefully. I've returned to this topic. Here is an overall comment on the patch: I think you are creating the patch based on the idea that async MergeAppend should work the same way as async Append: specifically, 1) introduce common functionality for that by making really large/invasive changes to the planner/executor around Append/MergeAppend, and then 2) (re-)implement async Append/MergeAppend on top of it. I'm very sorry to say this so late, but I think you are misguided from the beginning. Append/MergeAppend look similar, but they are actually different at least from the perspective of async execution (one such example is the ReScan handling we've discussed before). So I think we should implement async MergeAppend in a more optimized way, separately from async Append. To put it another way, I think it's *too* early to consider refactoring like #1. If both async Append/MergeAppend were (almost) finished, we could do so, but they would actually be far from finished, so doing the refactoring at this point would just make the future maintenance/development of them hard. Again, they are actually different. I think it's a good idea to do refactoring to share between them some code like the guts of ExecAppendAsyncEventWait() in async Append, though. I've already started reworking on Alexander Pyhalov's original patch for that. I will post a reworked version as soon as possible. Best regards, Etsuro Fujita
