Skip site navigation (1) Skip section navigation (2)

Re: Autovacuum in the backend

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autovacuum in the backend
Date: 2005-06-16 13:06:55
Message-ID: (view raw or whole thread)
Lists: pgsql-generalpgsql-hackers
swm(at)linuxworld(dot)com(dot)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.
"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

In response to


pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2005-06-16 13:47:24
Subject: Re: Autovacuum in the backend
Previous:From: Tom LaneDate: 2005-06-16 12:56:31
Subject: Re: Escape handling in strings

pgsql-general by date

Next:From: Ilja GolshteinDate: 2005-06-16 13:21:35
Subject: Re: Hungry postmaster
Previous:From: rodDate: 2005-06-16 13:06:19
Subject: Re: pg_dumpall

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group