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

Re: [HACKERS] More detail on settings for pgavd?

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,Shridhar Daithankar <shridhar_daithankar(at)myrealbox(dot)com>,pgsql-performance(at)postgresql(dot)org,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] More detail on settings for pgavd?
Date: 2003-11-21 21:23:18
Message-ID: 200311211323.19003.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Matthew,

> Actually, this might be a necessary addition as pg_autovacuum currently 
> suffers from the startup transients that the FSM used to suffer from, 
> that is, it doesn't remember anything that happened the last time it 
> ran.  A pg_autovacuum database could also be used to store thresholds 
> and counts from the last time it ran.

I don't see how a seperate database is better than a table in the databases., 
except that it means scanning only one table and not one per database.   For 
one thing, making it a seperate database could make it hard to back up and 
move your database+pg_avd config.

But I don't feel strongly about it.

> Where are you getting 13% from? 

13% * 3/4 ~~ 10%

And I think both of use agree that vacuuming tables with less than 10% changes 
is excessive and could lead to problems on its own, like overlapping vacuums.

>  Do you know of an easy way to get a 
> count of the total pages used by a whole cluster?

Select sum(relpages) from pg_class.

> I do like the concept though as long as we find good values for 
> min_fsm_percentage and min_autovac_scaling_factor.

See above.  I propose 0.13 and 0.1

> Which we already keep a copy of inside of pg_autovacuum, and update 
> after we issue a vacuum.

Even easier then.

BTW, do we have any provisions to avoid overlapping vacuums?  That is, to 
prevent a second vacuum on a table if an earlier one is still running?

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


In response to

Responses

pgsql-performance by date

Next:From: Matthew T. O'ConnorDate: 2003-11-21 21:24:25
Subject: Re: [HACKERS] More detail on settings for pgavd?
Previous:From: Josh BerkusDate: 2003-11-21 17:09:00
Subject: Re: [HACKERS] More detail on settings for pgavd?

pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2003-11-21 21:24:25
Subject: Re: [HACKERS] More detail on settings for pgavd?
Previous:From: Oli SennhauserDate: 2003-11-21 21:18:26
Subject: Re: Release cycle length

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