Re: Lock-free compaction. Why not?

That is a very useful thread and I'll keep on following it but it is not
exactly what I'm trying to achieve here.
You see, there is a great difference between VACUUM FULL CONCURRENTLY and
adding compaction to lazy vacuuming. The main factor here is resource
utilization: a lot of companies have enough data that would need days to be
vacuumed concurrently. Is the implementation discussed there pausable or at
least cancellable? Does it take into account periods of high resource
utilization by user-generated queries?

On Mon, Jul 22, 2024 at 9:42 AM Michael Banck <mbanck(at)gmx(dot)net> wrote:

> Hi,
>
> On Mon, Jul 22, 2024 at 08:39:23AM -0400, Robert Haas wrote:
> > What the extensions that are out there seem to do is, as I understand
> > it, an online table rewrite with concurrent change capture, and then
> > you apply the changes to the output table afterward. That has the
> > problem that if the changes are happening faster than you can apply
> > them, the operation does not terminate. But, enough people seem to be
> > happy with this kind of solution that we should perhaps look harder at
> > doing something along these lines in core.
>
> I believe this is being discussed here:
>
> https://commitfest.postgresql.org/49/5117/
> https://www.postgresql.org/message-id/5186.1706694913%40antos
>
>
> Michael
>