| From: | Madhav Madhusoodanan <madhavmadhusoodanan(at)gmail(dot)com> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Kirk Wolak <wolakk(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
| Subject: | Re: [WiP] B-tree page merge during vacuum to reduce index bloat |
| Date: | 2026-03-11 09:40:22 |
| Message-ID: | CAKw2Pb2ga_MKhc4HsfiO9xKNcCUv2H=wg3zxMR4=EBPDNWEcfA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 10, 2026 at 5:23 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> They're exclusively for btree code's use; extensions (*) must not add
> to (or change the meaning of) those bits, lest they create a forward
> incompatibility with core PostgreSQL btree code in newer major
> versions; it would cause corrupted binary upgraded databases.
> But patches against core btree code can use those bits, because
> forward compatibility is less of an issue there - we don't really
> support binary upgrades manually patched systems, especially if they
> have incompatible on-disk data.
Noted, I'm looking at it from the core btree code side of things.
I'm unable to see a way where scans or VACUUM calls can recognise
transient merge states if we implement merging as an extension.
Madhav
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shiju Sivadazz | 2026-03-11 09:45:28 | Question about heap_inplace_update and VACUUM behavior |
| Previous Message | Jim Jones | 2026-03-11 09:20:18 | Re: Add XMLNamespaces to XMLElement |