> On 29 Aug 2025, at 13:39, Andrey Borodin wrote:
>
> I think to establish baseline for locking correctness we are going to start
> from writing index scan tests, that fail with proposed merge patch and pass
> on current HEAD. I want to observe that forward scan is showing duplicates
> and b
Peter, Matthias, many thanks for your input!
> On 28 Aug 2025, at 01:06, Peter Geoghegan wrote:
>
> Have you benchmarked it?
Kind of. Here are bloat charts from random production clusters:
Upper green line has an axis on right - it's total index bloat per cluster.
Other lines are individual
On Tue, Aug 26, 2025 at 5:40 AM Andrey Borodin wrote:
> *** Correctness:
>
> The implementation reuses existing locking, critical sections and WAL logging
> infrastructure. To handle cross-page dependencies during WAL replay, when
> tuples are merged, the right sibling buffer is registered with
On Tue, Aug 26, 2025 at 6:33 AM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Tue, 26 Aug 2025 at 11:40, Andrey Borodin wrote:
> >
> > Hi hackers,
> >
> > Together with Kirk and Nik we spent several online hacking sessions to
> tackle index bloat problems [0,1,2]. As a result
On Tue, 26 Aug 2025 at 11:40, Andrey Borodin wrote:
>
> Hi hackers,
>
> Together with Kirk and Nik we spent several online hacking sessions to tackle
> index bloat problems [0,1,2]. As a result we concluded that B-tree index page
> merge should help to keep an index from pressuring shared_buffer
Hi hackers,
Together with Kirk and Nik we spent several online hacking sessions to tackle
index bloat problems [0,1,2]. As a result we concluded that B-tree index page
merge should help to keep an index from pressuring shared_buffers.
We are proposing a feature to automatically merge nearly-emp
