DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=vMj/JI1ng4NMLgMktUDz9/S/d+y+1Al2A0PQrGusbFUS0QdWEHqziLKXgouWwMz1o4GTomLuOYmhexkKeEIRqFfXONfva/fTyfGE+f1AMpEKCzi50TkE/EWE7/24tM/5Silwfdvu4/KLkfacMHhEbYHnoSTrw3sAwZx4fbF3T8E=
Message-ID: <2e78013d0804170316v2b62d7afy87c3753fb0b55842@mail.gmail.com>
Date: Thu, 17 Apr 2008 15:46:05 +0530
From: "Pavan Deolasee" <pavan.deolasee@gmail.com>
To: "Gunther Mayer" <gunther.mayer@googlemail.com>
Subject: Re: Exact index overhead
Cc: pgsql-performance@postgresql.org
In-Reply-To: <48071807.8000409@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <48071807.8000409@gmail.com>

On Thu, Apr 17, 2008 at 2:57 PM, Gunther Mayer
<gunther.mayer@googlemail.com> wrote:
>
>
>  You see, all updates change most of the data fields but never ever touch
> the time field. Assuming correct and efficient behaviour of postgresql it
> should then also never touch the time index and incur zero overhead in its
> presence, but is this really the case?

Normally, whenever a row is updated, Postgres inserts a new index entry in each
of the index. So to answer your question, there is certainly index
overhead during
updates, even if you are not changing the indexed column.

But if you are using 8.3 then HOT may help you here, assuming you are
not updating
any index keys. HOT optimizes the case by *not* inserting a new index entry and
also by performing retail vacuuming. The two necessary conditions for HOT are:

1. Update should not change any of the index keys. So if you have two
indexes, one
on column A and other on column B, update must not be modifying either A or B.

2. The existing block should have enough free space to accommodate the
new version
A less than 100 fillfactor may help you given your rate of updates.

If your application satisfies 1, then I would suggest you to upgrade
to 8.3 (if you are
not using it already) and then you can create the index without
bothering much about
overheads.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com