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: m3ekb2zc0g.fsf@knuth.cbbrowne.com (view raw or flat)
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.
-- 
"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

In response to

Responses

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-2014 The PostgreSQL Global Development Group