Re: why there is not VACUUM FULL CONCURRENTLY?

Поиск
Список
Период
Сортировка
От Kirill Reshke
Тема Re: why there is not VACUUM FULL CONCURRENTLY?
Дата
Msg-id CALdSSPig+9SVK34EN33v6-iFh17FFNLxW0cpHToX=miNLDqodg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: why there is not VACUUM FULL CONCURRENTLY?  (Antonin Houska <ah@cybertec.at>)
Ответы Re: why there is not VACUUM FULL CONCURRENTLY?
Re: why there is not VACUUM FULL CONCURRENTLY?
Список pgsql-hackers
Hi!
I'm interested in the vacuum concurrently feature being inside the
core, so will try to review patch set and give valuable feedback. For
now, just a few little thoughts..


> The first version is attached. The actual feature is in 0003. 0004 is probably
> not necessary now, but I haven't realized until I coded it.

The logical replication vacuum approach is a really smart idea, I like
it. As far as I understand, pg_squeeze works well in real production
databases, which
gives us hope that the vacuum concurrent feature in core will be good
too... What is the size of the biggest relation successfully vacuumed
via pg_squeeze?
Looks like in case of big relartion or high insertion load,
replication may lag and never catch up...

However, in general, the 3rd patch is really big, very hard to
comprehend.  Please consider splitting this into smaller (and
reviewable) pieces.
Also, we obviously need more tests on this. Both tap-test and
regression tests I suppose.

One more thing is about pg_squeeze background workers. They act in an
autovacuum-like fashion, aren't they? Maybe we can support this kind
of relation processing in core too?



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

Предыдущее
От: Ahmed Yarub Hani Al Nuaimi
Дата:
Сообщение: Re: Lock-free compaction. Why not?
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: why there is not VACUUM FULL CONCURRENTLY?