Re: why there is not VACUUM FULL CONCURRENTLY? - Mailing list pgsql-hackers

From Kirill Reshke
Subject Re: why there is not VACUUM FULL CONCURRENTLY?
Date
Msg-id CALdSSPig+9SVK34EN33v6-iFh17FFNLxW0cpHToX=miNLDqodg@mail.gmail.com
Whole thread Raw
In response to Re: why there is not VACUUM FULL CONCURRENTLY?  (Antonin Houska <ah@cybertec.at>)
Responses Re: why there is not VACUUM FULL CONCURRENTLY?
Re: why there is not VACUUM FULL CONCURRENTLY?
Re: why there is not VACUUM FULL CONCURRENTLY?
List 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 by date:

Previous
From: Ahmed Yarub Hani Al Nuaimi
Date:
Subject: Re: Lock-free compaction. Why not?
Next
From: Pavel Stehule
Date:
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?