swm@linuxworld.com.au (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.
--
"cbbrowne","@","gmail.com"
http://linuxfinances.info/info/languages.html
"I can't escape the sensation that I have already been thinking in
Lisp all my programming career, but forcing the ideas into the
constraints of bad languages, which explode those ideas into a
bewildering array of details, most of which are workarounds for the
language." -- Kaz Kylheku
