On Thu, Sep 3, 2026 at 9:36 AM Amit Langote <[email protected]> wrote: > Thoughts on removing batching while retaining the per-row fast path in > v19, and on retaining batching in its current state in master for v20 > development, would be welcome.
Does this approach have any significant downsides that we should be thinking about? For example, are we relying on the batching to buy back slowdowns that the per-row fast path might otherwise introduce in some cases? Or is this just a case of the per-row fast path is an optimization and then the batching is a further optimization, so if the second one is buggy we can take it out without causing any problems for the first one? I do think I generally agree that the batching stuff feels much riskier than the per-row fast path stuff. I think batching in this context intrinsically requires changing the timing of trigger firing, and that is risky because (1) important things may be different at the two timings, such as the choice of snapshot, and (2) the change in timing may be user-perceptible in some way. However, I'm not entirely sure whether (1) batching is in good enough shape that it makes sense to keep it in v20 or (2) the per-row fast-path is in good enough shape to stay in v19. In other words, I think we should do at least as much as what you're proposing here, but possibly more. However, I'm not very sure what the right answer is at this point. -- Robert Haas EDB: http://www.enterprisedb.com
