From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Autovacuum in the backend |
Date: | 2005-06-17 16:21:44 |
Message-ID: | 42B2F898.7060806@zeut.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Christopher Browne wrote:
>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.
>
>
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Zlatko Matic | 2005-06-17 17:23:43 | Re: pg_dumpall |
Previous Message | Josh Berkus | 2005-06-17 16:18:53 | Re: Autovacuum in the backend |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-17 16:22:32 | Re: Utility database (Was: RE: Autovacuum in the backend) |
Previous Message | Josh Berkus | 2005-06-17 16:18:53 | Re: Autovacuum in the backend |