Re: Revert RI fast-path batching from REL_19_STABLE

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, rmt(at)lists(dot)postgresql(dot)org
Subject: Re: Revert RI fast-path batching from REL_19_STABLE
Date: 2026-09-10 03:57:08
Message-ID: CAA4eK1JOg-5WPm8qLFbYE5ri-dGT49dY5g_MPOK+W8b0STW45Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 9, 2026 at 9:12 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Wed, Sep 9, 2026 at 8:26 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> >
> > That still leaves your concern about whether the per-row path is
> > sufficiently solid for v19. The snapshot fixes and Amit's recent
> > collation report show that there are differences from SPI that we (I)
> > missed. The proposed collation fix falls back to SPI when the
> > referenced index and column collations differ. I still propose
> > retaining the per-row path, but agree that its readiness needs to be
> > assessed separately from the decision to remove batching.
>
> I think a good start would be to revert the batching ASAP so that we
> can consider the state after independently.
>

BTW, it is not clear to me from this response whether it should be
reverted for both 19 and 20 or just 19? I feel the reason to keep in
20 could be that it needs some (known) adjustments/bug-fixes and more
testing but if there are still larger design issues, it will be better
to revert even from 20. I was planning to evaluate that part but that
needs more time, so it is better to first revert batching from 19, fix
some reported issues for per-row optimization and evaluate whether it
has any serious issues and make a decision based on that. Then
independently, we can evaluate the batching state for 20 and take a
call.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2026-09-10 03:59:53 Re: pg_get_*_ddl() needs a redesign
Previous Message shihao zhong 2026-09-10 03:53:57 Re: logical decoding: skip unnecessary snapshot distribution.