[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. -- "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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
