Re: Automatic free space map filling - Mailing list pgsql-hackers

From Csaba Nagy
Subject Re: Automatic free space map filling
Date
Msg-id 1141376884.3327.58.camel@coppola.muc.ecircle.de
Whole thread Raw
In response to Re: Automatic free space map filling  ("Matthew T. O'Connor" <matthew@zeut.net>)
Responses Re: Automatic free space map filling  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
> Are you running 8.1?  If so, you can use autovacuum and set per table 
> thresholds (read vacuum aggressivly) and per table cost delay settings 
> so that the performance impact is minimal.  If you have tried 8.1 
> autovacuum and found it unhelpful, I would be curious to find out why.

Yes, I'm running 8.1, and I've set up per table auto-vacuum settings :-)
And I lowered the general thresholds too. Generally autovacuum is very
useful from my POV, and in particular the per table settings are so.

But the problem I have is not the performance impact of the vacuum
itself, but the impact of the long running transaction of vacuuming big
tables. I do have big tables which are frequently updated and small
tables which are basically queue tables, so each inserted row will be
updated a few times and then deleted. Those queue tables tend to get
huge unvacuumable dead space during any long running transaction, and
vacuum on the big tables is such a long running transaction. And I have
a few of them, and one is in particular very busy (a task table, all
activities go through that one).

Now when the queue tables get 1000 times dead space compared to their
normal size, I get performance problems. So tweaking vacuum cost delay
doesn't buy me anything, as not vacuum per se is the performance
problem, it's long run time for big tables is.

Cheers,
Csaba.




pgsql-hackers by date:

Previous
From: Lukas Smith
Date:
Subject: Re: column order in GROUP BY
Next
From: George Weaver
Date:
Subject: Re: [NOVICE] pg_config --pgxs