X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id E41DC3A49AE;
	Thu,  4 Nov 2004 22:26:20 +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 48754-07; Thu,  4 Nov 2004 22:26:12 +0000 (GMT)
Received: from hub.org (hub.org [200.46.204.220])
	by svr1.postgresql.org (Postfix) with ESMTP id C33D73A4983;
	Thu,  4 Nov 2004 22:26:10 +0000 (GMT)
Received: from localhost (unknown [200.46.204.144])
	by hub.org (Postfix) with ESMTP id 9C53412AE54;
	Thu,  4 Nov 2004 18:26:07 -0400 (AST)
Received: from hub.org ([200.46.204.220])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 46999-09; Thu,  4 Nov 2004 22:26:06 +0000 (GMT)
Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91])
	by hub.org (Postfix) with ESMTP id 3061312A845;
	Thu,  4 Nov 2004 18:26:06 -0400 (AST)
Received: by ganymede.hub.org (Postfix, from userid 1000)
	id A6BB735271; Thu,  4 Nov 2004 18:26:08 -0400 (AST)
Received: from localhost (localhost [127.0.0.1])
	by ganymede.hub.org (Postfix) with ESMTP id A582D344D3;
	Thu,  4 Nov 2004 18:26:08 -0400 (AST)
Date: Thu, 4 Nov 2004 18:26:08 -0400 (AST)
From: "Marc G. Fournier" <scrappy@postgresql.org>
X-X-Sender: scrappy@ganymede.hub.org
To: Justin Clift <justin@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [pgsql-www] pg_autovacuum is nice ... but ...
In-Reply-To: <418AA915.7010903@postgresql.org>
Message-ID: <20041104182322.D21566@ganymede.hub.org>
References: <20041103155855.O82047@ganymede.hub.org>
	<41895BDA.1090903@postgresql.org>
	<20041103201625.S82047@ganymede.hub.org>
	<19430.1099533223@sss.pgh.pa.us> <418AA915.7010903@postgresql.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: by amavisd-new at hub.org
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/149
X-Sequence-Number: 60721


Moved to -hackers where this belongs :)

On Fri, 5 Nov 2004, Justin Clift wrote:

> 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.

I'm not sure if I like this one too much ... but it would be nice if 
something like this triggered a warning in the logs, maybe a feature of 
pg_autovacuum itself?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664