Christopher Browne wrote:
[EMAIL PROTECTED] (Gavin Sherry) wrote:
I guess the main point is, if something major like this ships in the
backend it says to users that the problem has gone away. pg_autovacuum is
a good contrib style solution: it addresses a problem users have and
attempts to solve it the way other users might try and solve it. When you
consider it in the backend, it looks like a workaround. I think users are
better served by solving the real problem.
Hear, hear!
It seems to me that the point in time at which it is *really*
appropriate to put this into the backend is when the new GUC variable
"dead_tuple_map_size" (akin to FSM) is introduced, and there is a new
sort of 'VACUUM DEAD TUPLES' command which goes through the DTPM (Dead
Tuple Page Map).
In THAT case, there would be the ability to do a VACUUM on the "dead
bits" of the table that consists of 50M rows without having to go
through the 49M rows that haven't been touched in months.
This will make VACUUM less painful, but it doesn't eliminate the need /
desire for autovacuum. I agree this would be good, but I see it as a
separate issue.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
