Re: Autovacuum in the backend
От | Matthew T. O'Connor |
---|---|
Тема | Re: Autovacuum in the backend |
Дата | |
Msg-id | 42B2F898.7060806@zeut.net обсуждение исходный текст |
Ответ на | Re: Autovacuum in the backend (Christopher Browne <cbbrowne@acm.org>) |
Ответы |
Re: Autovacuum in the backend
|
Список | pgsql-hackers |
Christopher Browne wrote: >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. > > 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.
В списке pgsql-hackers по дате отправления: