Re: pg_autovacuum is nice ... but ...

From: Justin Clift <justin(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-www(at)postgresql(dot)org
Subject: Re: pg_autovacuum is nice ... but ...
Date: 2004-11-04 22:11:33
Message-ID: 418AA915.7010903@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

Tom Lane wrote:
<snip>
> Yup. 20000 < 23072, so you're losing some proportion of FSM entries.
> What's worse, the FSM relation table is maxed out (1000 = 1000) which
> suggests that there are relations not being tracked at all; you have
> no idea how much space is getting leaked in those.
>
> You can determine the number of relations potentially needing FSM
> entries by
> select count(*) from pg_class where relkind in ('r','i','t');
> --- sum over all databases in the cluster to get the right result.
>
> Once you've fixed max_fsm_relations, do vacuums in all databases, and
> then vacuum verbose should give you a usable lower bound for
> max_fsm_pages.

Would making max_fsm_relations and max_fsm_pages dynamically update
themselves whilst PostgreSQL runs be useful? Sounds like they're the
kind of things that many people would receive maximum benefit if
PostgreSQL altered these settings as needed itself.

?

Regards and best wishes,

Justin Clift

> regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2004-11-04 22:20:17 Re: CVS should die (was: Possible make_oidjoins_check
Previous Message Gaetano Mendola 2004-11-04 21:50:16 Wrong on-line documentation version

Browse pgsql-www by date

  From Date Subject
Next Message Marc G. Fournier 2004-11-04 22:26:08 Re: [pgsql-www] pg_autovacuum is nice ... but ...
Previous Message World Wide Web Owner 2004-11-04 20:46:52 New Event