Re: Autovacuum in the backend

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <swm(at)linuxworld(dot)com(dot)au>
Cc: <postgres(at)cybertec(dot)at>, <matthew(at)zeut(dot)net>, <alvherre(at)surnet(dot)cl>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autovacuum in the backend
Date: 2005-06-16 10:55:40
Message-ID: 4813.24.211.165.134.1118919340.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Gavin Sherry said:
> On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
>
>> > 2) By no fault of its own, autovacuum's level of granularity is the
>> > table level. For people dealing with non-trivial amounts of data
>> > (and we're not talking gigabytes or terabytes here), this is a
>> > serious drawback. Vacuum at peak times can cause very intense IO
>> > bursts -- even with the enhancements in 8.0. I don't think the
>> > solution to the problem is to give users the impression that it is
>> > solved and then vacuum their tables during peak periods. I cannot
>> > stress this enough.
>>
>>
>> I completly agree with Gavin - integrating this kind of thing into the
>> backend writer or integrate it with FSM would be the ideal solution.
>>
>> I guess everybody who has already vacuumed a 2 TB relation will agree
>> here. VACUUM is not a problem for small "my cat Minka" databases.
>> However, it has been a real problem on large, heavy-load databases. I
>> have even seen people splitting large tables and join them with a view
>> to avoid long vacuums and long CREATE INDEX operations (i am not
>> joking - this is serious).
>
> I think this gets away from my point a little. People with 2 TB tables
> can take care of themselves, as can people who've taken the time to
> partition their tables to speed up vacuum. I'm more concerned about the
> majority of people who fall in the middle -- between the hobbiest and
> the high end data centre.
>

My only problemn with what you say is that we should not incorporate AV into
the backend until these things have been solved. This would be one step down
a long raod, and that's how it should be positioned.

I am very concerned that with Feature Freeze 2 weeks away we seem to be in a
similar position to where we were a year ago. I know we don't even promise
anything, but certainly I and others believed that work was being done to
get AV into the backend in 8.1. Not doing this because we think it could be
lots better would not give people a good impression of our processes. I
certainly don't think it will make matters worse, especially if it's not on
by default.

cheers

andrew

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sean Davis 2005-06-16 11:07:27 Re: Dynamic SQL
Previous Message Jiří Němec 2005-06-16 10:55:08 PostgreSQL log analyzer

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-06-16 12:35:49 Re: [HACKERS] INHERITS and planning
Previous Message Dave Page 2005-06-16 10:42:40 Re: Autovacuum in the backend