X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 22E589DC83F for ; Wed, 18 Jan 2006 15:15:56 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 07342-09 for ; Wed, 18 Jan 2006 15:15:56 -0400 (AST) Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 112A29DC820 for ; Wed, 18 Jan 2006 15:15:54 -0400 (AST) Received: from www.conducivetech.com (conducivetech.com [64.65.134.45]) by svr4.postgresql.org (Postfix) with ESMTP id D37A05AF036 for ; Wed, 18 Jan 2006 19:15:54 +0000 (GMT) Received: from dentaku.sight-n-sound.com (dentaku.sight-n-sound.com [198.107.31.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.conducivetech.com (Postfix) with ESMTP id C70931838F for ; Wed, 18 Jan 2006 11:15:51 -0800 (PST) From: Michael Crozier To: pgsql-performance@postgresql.org Subject: Re: Autovacuum / full vacuum (off-topic?) Date: Wed, 18 Jan 2006 11:15:51 -0800 User-Agent: KMail/1.8.3 References: <034701c61c46$f427df20$f20214ac@bite.lt> <60d5ipcw8y.fsf@dba2.int.libertyrms.com> In-Reply-To: <60d5ipcw8y.fsf@dba2.int.libertyrms.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601181115.51850.crozierm@conducivetech.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200601/307 X-Sequence-Number: 16785 On Wednesday 18 January 2006 08:54 am, Chris Browne wrote: > To the contrary, there is a whole section on what functionality to > *ADD* to VACUUM. Near but not quite off the topic of VACUUM and new features... I've been thinking about parsing the vacuum output and storing it in Postgresql. All the tuple, page, cpu time, etc... information would be inserted into a reasonably flat set of tables. The benefits I would expect from this are: * monitoring ability - I could routinely monitor the values in the table to warn when vacuum's are failing or reclaimed space has risen dramatically. I find it easier to write and maintain monitoring agents that perform SQL queries than ones that need to routinely parse log files and coordinate with cron. * historical perspective on tuple use - which a relatively small amount of storage, I could use the vacuum output to get an idea of usage levels over time, which is beneficial for planning additional capacity * historical information could theoretically inform the autovacuum, though I assume there are better alternatives planned. * it could cut down on traffic on this list if admin could see routine maintenance in a historical context. Assuming this isn't a fundamentally horrible idea, it would be nice if there were ways to do this without parsing the pretty-printed vacuum text (ie, callbacks, triggers, guc variable). I'd like to know if anybody does this already, thinks its a bad idea, or can knock me on the noggin with the pg manual and say, "it's already there!". Regards, Michael