X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id CB26052BD2 for ; Mon, 18 Jul 2005 15:21:19 -0300 (ADT) 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 23253-01 for ; Mon, 18 Jul 2005 18:21:14 +0000 (GMT) Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146]) by svr1.postgresql.org (Postfix) with ESMTP id DE9A452C26 for ; Mon, 18 Jul 2005 15:21:12 -0300 (ADT) Received: from sherman.stortek.com (localhost [127.0.0.1]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j6IILDD4000405 for ; Mon, 18 Jul 2005 12:21:13 -0600 (MDT) Received: from unix.stortek.com (burma.stortek.com [129.80.16.110]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j6IILCDC000402; Mon, 18 Jul 2005 12:21:12 -0600 (MDT) Received: from C118181.stortek.com (c118181.stortek.com [129.80.81.172]) by unix.stortek.com (8.12.10/8.12.0) with ESMTP id j6IILBvn028899; Mon, 18 Jul 2005 12:21:11 -0600 (MDT) Date: Mon, 18 Jul 2005 12:21:03 -0600 From: Robert Creager To: Tom Lane Cc: matthew@zeut.net, pgsql-performance@postgresql.org, Andy Hewitt III Subject: Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Message-ID: <20050718122103.0000064a@C118181.stortek.com> In-Reply-To: <15472.1121709173@sss.pgh.pa.us> References: <20050718114952.00004ac5@C118181.stortek.com> <15472.1121709173@sss.pgh.pa.us> Organization: StorageTek X-Mailer: Sylpheed-Claws 1.0.4.1 Win32 (GTK+ 1.3.0; Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200507/265 X-Sequence-Number: 13506 On Mon, 18 Jul 2005 13:52:53 -0400 Tom Lane wrote: > Start a fresh psql session and "SHOW vacuum_cost_delay" to verify what > the active setting is. Thanks. It does show 0 for 803 in a session that was up since I thought I had HUPed the server with the new value. This is leading me to believe that 803 doesn't do very well with VACUUM ANALYZE running often, at least in my particular application... I will provide a more definitive statement to that affect, hopefully tonight. Cheers, Rob