Re: Lock-free compaction. Why not?

Wow I was busy for a controle of days and now I’m again fully committed to
this initiative. These ideas are extremely useful to my. I’ll first start
by reading the old in-place implementation, but meanwhile I have the
following questions:
1- I’m thinking of adding only one simple step to be auto-vacuum. This
means that there will neither be excessive locking nor resource
utilization. I guess my question is: does that simple step make the current
lazy auto-vacuum much worse?
2- Can you point me to a resource explaining why this might lead to index
bloating?

Em qui., 18 de jul. de 2024 às 15:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Jul 18, 2024 at 7:08 AM David Rowley <dgrowleyml(at)gmail(dot)com>
> wrote:
> >> I think the primary issue with the old way was index bloat wasn't
> >> fixed. The release notes for 9.0 do claim the CLUSTER method "is
> >> substantially faster in most cases", however, I imagine there are
> >> plenty of cases where it wouldn't be. e.g, it's hard to imagine
> >> rewriting the entire 1TB table and indexes is cheaper than moving 1
> >> row out of place row.
>
> > The other thing I remember besides index bloat is that it was
> > crushingly slow.
>
> Yeah. The old way was great if there really were just a few tuples
> needing to be moved ... but by the time you decide you need VACUUM
> FULL rather than plain VACUUM, that's unlikely to be the case.
>
> regards, tom lane
>