X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 0A46C9FB1FB for ; Sat, 8 Jul 2006 06:17:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 19578-06 for ; Sat, 8 Jul 2006 06:17:05 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from cronos.madness.at (madness.at [217.196.146.217]) by postgresql.org (Postfix) with ESMTP id F3DBC9FB1DA for ; Sat, 8 Jul 2006 06:17:05 -0300 (ADT) Received: from mastermind.kaltenbrunner.cc ([83.215.233.60]) by cronos.madness.at with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1Fz8vf-000KED-0I; Sat, 08 Jul 2006 11:17:02 +0200 Message-ID: <44AF77FE.5040901@kaltenbrunner.cc> Date: Sat, 08 Jul 2006 11:16:46 +0200 From: Stefan Kaltenbrunner User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: "Steinar H. Gunderson" CC: pgsql-performance@postgresql.org Subject: Re: VACUUM vs. REINDEX References: <6.2.3.0.2.20060707145857.0342ca58@mail.pandimensional.com> <6.2.3.0.2.20060707163917.06ae3ea8@mail.brownpapertickets.com> <6.2.3.0.2.20060707174316.0742f670@mail.brownpapertickets.com> <1d219a6f0607071828q1d63fe55k8a1faeccf03b0884@mail.gmail.com> <20060708081316.GB6396@uio.no> In-Reply-To: <20060708081316.GB6396@uio.no> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/83 X-Sequence-Number: 19943 Steinar H. Gunderson wrote: > On Fri, Jul 07, 2006 at 09:28:52PM -0400, Chris Hoover wrote: >> You need to increase your fsm settings. The database is telling you it is >> trying to store 177K+ pages, but you have only provided it with 20K. Since >> these pages are cheap, I would set your fsm up with at least the following. > > While we're at it, is there a good reason why we simply aren't upping the FSM > defaults? It seems like a lot of people are being bitten by it, and adding > more pages and relations is as you say cheap... that is already done in -HEAD at the initdb stage: ... selecting default shared_buffers/max_fsm_pages ... 4000/200000 ... Stefan