Re: Lock-free compaction. Why not?

Поиск
Список
Период
Сортировка
От Ahmed Yarub Hani Al Nuaimi
Тема Re: Lock-free compaction. Why not?
Дата
Msg-id CAF239vpYgKV4sjjTQ_2qCDu00cSapj2hnU-YMwj6m5UC7TcQ=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Lock-free compaction. Why not?  (Michael Banck <mbanck@gmx.net>)
Ответы Re: Lock-free compaction. Why not?
Список pgsql-hackers
Дерево обсуждения
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@gmx.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Add privileges test for pg_stat_statements to improve coverage
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Incremental backup from a streaming replication standby fails