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 49CF39DC9C1 for ; Mon, 30 Jan 2006 19:26:26 -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 00597-08 for ; Mon, 30 Jan 2006 19:26:28 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id 12A3D9DC98B for ; Mon, 30 Jan 2006 19:26:21 -0400 (AST) Received: mir3-fs.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes.mirlogic.com by mir3-fs.mir3.com; 30 Jan 2006 15:26:23 -0800 Subject: Re: Query planner issue From: Mark Lewis To: Emmanuel Lacour Cc: pgsql-performance@postgresql.org In-Reply-To: <20060130225711.GE1320@easter-eggs.com> References: <20060130225711.GE1320@easter-eggs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Mon, 30 Jan 2006 15:26:23 -0800 Message-Id: <1138663583.28241.96.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.121 required=5 tests=[AWL=0.120, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 0.121 X-Spam-Level: X-Archive-Number: 200601/482 X-Sequence-Number: 16960 You have lots of dead rows. Do a vacuum full to get it under control, then run VACUUM more frequently and/or increase your FSM settings to keep dead rows in check. In 7.2 vacuum is pretty intrusive; it will be much better behaved once you can upgrade to a more recent version. You really, really want to upgrade as soon as possible, and refer to the on-line docs about what to do with your FSM settings. -- Mark Lewis On Mon, 2006-01-30 at 23:57 +0100, Emmanuel Lacour wrote: > Hi everybody, > > I have the following problem, on a test server, if I do a fresh import > of production data then run > 'explain analyze select count(*) from mandats;' > > I get this result: > > Aggregate (cost=6487.32..6487.32 rows=1 width=0) (actual time=607.61..607.61 rows=1 loops=1) > -> Seq Scan on mandats (cost=0.00..6373.26 rows=45626 width=0) (actual time=0.14..496.20 rows=45626 loops=1) > Total runtime: 607.95 msec > > > On the production server, if I do the same (without other use of the server), I get: > > Aggregate (cost=227554.33..227554.33 rows=1 width=0) (actual time=230705.79..230705.79 rows=1 loops=1) > -> Seq Scan on mandats (cost=0.00..227440.26 rows=45626 width=0) (actual time=0.03..230616.64 rows=45760 loops=1) > Total runtime: 230706.08 msec > > > > Is there anyone having an idea on how yo solve this poor performances? I > think it is caused by many delete/insert on this table every day, but > how to solve it, I need to run this qury each hour :(. I run > vacuum each night, postgresql is unfortunatly 7.2.1 :( (no upgrade > before 2 or 3 months). >