Re: Revert RI fast-path batching from REL_19_STABLE

On Thu, Sep 3, 2026 at 9:36 AM Amit Langote <amitlangote09(at)gmail(dot)com> 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