X-Original-To: pgsql-www-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 0C2A43A4920
	for <pgsql-www-postgresql.org@localhost.postgresql.org>;
	Thu,  4 Nov 2004 22:11:41 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 45292-03
	for <pgsql-www-postgresql.org@localhost.postgresql.org>;
	Thu,  4 Nov 2004 22:11:34 +0000 (GMT)
Received: from mail.iinet.net.au (mail-03.iinet.net.au [203.59.3.35])
	by svr1.postgresql.org (Postfix) with SMTP id A0C273A3CD3
	for <pgsql-www@postgresql.org>; Thu,  4 Nov 2004 22:11:34 +0000 (GMT)
Received: (qmail 10556 invoked from network); 4 Nov 2004 22:11:33 -0000
Received: from unknown (HELO ?192.168.10.3?) (203.217.57.146)
	by mail.iinet.net.au with SMTP; 4 Nov 2004 22:11:33 -0000
Message-ID: <418AA915.7010903@postgresql.org>
Date: Fri, 05 Nov 2004 09:11:33 +1100
From: Justin Clift <justin@postgresql.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Marc G. Fournier" <scrappy@postgresql.org>,
	pgsql-www@postgresql.org
Subject: Re: pg_autovacuum is nice ... but ...
References: <20041103155855.O82047@ganymede.hub.org>
	<41895BDA.1090903@postgresql.org>
	<20041103201625.S82047@ganymede.hub.org>
	<19430.1099533223@sss.pgh.pa.us>
In-Reply-To: <19430.1099533223@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests=
X-Spam-Level: 
X-Archive-Number: 200411/100
X-Sequence-Number: 5831

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