| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Amit Langote <amitlangote09(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-09 19:45:41 |
| Message-ID: | CA+TgmoZ=AeAbfk92L3v2_+eLMxV-w4AV8vXNVacuS5sM613zUw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 9, 2026 at 11:41 AM 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.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sehrope Sarkuni | 2026-09-09 19:52:35 | Re: Avoid streaming zero-filled WAL switch padding |
| Previous Message | Andrew Dunstan | 2026-09-09 19:12:26 | Re: pg_get_*_ddl() needs a redesign |