X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id AF850D9EC2;
	Mon,  3 Oct 2005 18:46:46 -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 46776-04; Mon,  3 Oct 2005 21:46:41 +0000 (GMT)
Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54])
	by svr1.postgresql.org (Postfix) with ESMTP id 1FA65D7E1D;
	Mon,  3 Oct 2005 18:46:42 -0300 (ADT)
Received: from 192.168.0.3 (unknown [84.12.188.233])
	by smtp.nildram.co.uk (Postfix) with ESMTP
	id 62266250AA5; Mon,  3 Oct 2005 22:46:41 +0100 (BST)
Subject: Re: [PERFORM] database bloat, but vacuums are done, and fsm seems
From: Simon Riggs <simon@2ndquadrant.com>
To: hubert depesz lubaczewski <depesz@gmail.com>
Cc: PostgreSQL General <pgsql-general@postgresql.org>,
	pgsqlperform <pgsql-performance@postgresql.org>
In-Reply-To: <9e4684ce05092800075d37d0cc@mail.gmail.com>
References: <9e4684ce05092800075d37d0cc@mail.gmail.com>
Content-Type: text/plain
Organization: 2nd Quadrant
Date: Mon, 03 Oct 2005 22:47:02 +0100
Message-Id: <1128376022.8603.137.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.068 required=5 tests=[AWL=0.018,
	FORGED_RCVD_HELO=0.05]
X-Spam-Level: 
X-Archive-Number: 200510/81
X-Sequence-Number: 84310

On Wed, 2005-09-28 at 09:07 +0200, hubert depesz lubaczewski wrote:
> database has quite huge load of updates, but i thought that vacum will
> guard me from database bloat, but from what i observed it means that
> vacuuming of b-tree indices is somewhat faulty.

No, thats perfectly normal.

Indices are packed tighter when they are first created and they spread
out a bit as you update the database. Blocks start at 90% full and end
up at 50% full for non-monotonic indexes (e.g. SERIAL) or 67% for
monotonic.

It's a long debated design feature on any DBMS that uses b-trees.

REINDEX or dump/restore should be identical.

Best Regards, Simon Riggs