Re: Lock-free compaction. Why not? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Lock-free compaction. Why not?
Date
Msg-id CA+TgmoY6BOeYfdd+eSR+i4QEFEi35icceeyqur0_29-9rD_Lgw@mail.gmail.com
Whole thread Raw
In response to Re: Lock-free compaction. Why not?  (Ahmed Yarub Hani Al Nuaimi <ahmedyarubhani@gmail.com>)
Responses Re: Lock-free compaction. Why not?
List pgsql-hackers
On Mon, Jul 22, 2024 at 1:00 PM Ahmed Yarub Hani Al Nuaimi
<ahmedyarubhani@gmail.com> wrote:
> 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
mainfactor 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
ofhigh resource utilization by user-generated queries? 

If you want to discuss the patch on the other thread, you should go
read that thread and perhaps reply there, rather than replying to this
message. It's important to keep all of the discussion of a certain
patch together, which doesn't happen if you reply like this.

Also, you've already been asked not to top-post and you just did it
again, so I'm guessing that you don't know what is meant by the term.
So please read this:

https://web.archive.org/web/20230608210806/idallen.com/topposting.html

If you're going to post to this mailing list, it is important to
understand the conventions and expectations that people have here. If
you insist on doing things differently than what everyone else does,
you're going to annoy a lot of people.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: [18] Policy on IMMUTABLE functions and Unicode updates
Next
From: "David E. Wheeler"
Date:
Subject: Re: jsonpath: Inconsistency of timestamp_tz() Output