X-Original-To: pgsql-performance@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 544B4475DBC for ; Mon, 24 Feb 2003 12:20:34 -0500 (EST) Received: from postgresql.org ([64.49.215.8]) by localhost (postgresql.org [64.49.215.8:10024]) (amavisd-new) with SMTP id 13945-10 for ; Mon, 24 Feb 2003 12:20:23 -0500 (EST) Received: from localhost.localdomain (unknown [65.217.53.66]) by postgresql.org (Postfix) with ESMTP id 83EC6475E1F for ; Mon, 24 Feb 2003 11:58:44 -0500 (EST) Received: from thorn.mmrd.com (thorn.mmrd.com [172.25.10.100]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h1OHQj6P021455; Mon, 24 Feb 2003 12:26:45 -0500 Received: from gnvex001.mmrd.com (gnvex001.mmrd.com [192.168.3.55]) by thorn.mmrd.com (8.11.6/8.11.6) with ESMTP id h1OGwXp26234; Mon, 24 Feb 2003 11:58:33 -0500 Received: from camel.mmrd.com ([172.25.5.213]) by gnvex001.mmrd.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F3HTHC59; Mon, 24 Feb 2003 11:58:32 -0500 Subject: Re: slow query From: Robert Treat To: Oleg Lebedev Cc: Josh Berkus , "pgsql-performance@postgresql.org" In-Reply-To: <993DBE5B4D02194382EC8DF8554A5273033587@postoffice.waterford.org> References: <993DBE5B4D02194382EC8DF8554A5273033587@postoffice.waterford.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Feb 2003 11:58:33 -0500 Message-Id: <1046105913.1014.66.camel@camel> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-new X-Archive-Number: 200302/174 X-Sequence-Number: 1230 On Mon, 2003-02-24 at 10:59, Oleg Lebedev wrote: > Thanks everybody for your help. > VACUUM FULL did the job, and now the query performance is the same in > both databases. I am surprised that FULL option makes such a dramatic > change to the query performance: from 4min. to 5sec.!!! It also changed > planner stats from ~9 sec to ~8sec. If your seeing wildly dramatic improvments from vacuum full, you might want to look into running regular vacuums more often (especially for high turnover tables), increase your max_fsm_relations to 1000, and increasing your max_fsm_pages. Robert Treat