DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=BoBoN3mF6M3wNt1vpw7rrDqaVjQF/H/Ikzk2BCWZv6POs8oynOO6XMkH1hHBFY1Cu5XrVv77gp3XCZaC6RyUUFZm+vLKJI9b8YfUckFJd7BxsG1G4WTfqdP4xK5nkyJDBFz5Xt2p6Ce9g2/FArEHSzAAF/VfPY01p1vQWeD9BAo=
Message-ID: <48072047.7030407@enterprisedb.com>
Date: Thu, 17 Apr 2008 13:02:47 +0300
From: Heikki Linnakangas <heikki@enterprisedb.com>
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110)
MIME-Version: 1.0
To: Gunther Mayer <gunther.mayer@googlemail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Exact index overhead
References: <48071807.8000409@gmail.com>
In-Reply-To: <48071807.8000409@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gunther Mayer 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? If it somehow does update 
> the index too even though the value hasn't changed by some weird 
> implementation detail I'd rather not have that index and live with slow 
> queries for the few times a day that reporting is run.

Updates do generally modify the indexes as well. The way MVCC has been 
implemented in PostgreSQL, UPDATE is internally very much like 
DELETE+INSERT. A new row version is inserted, new index pointers are 
added for the new row version, and the old row version is marked as deleted.

In version 8.3, however, the new HOT feature reduces the need for that. 
In a nutshell, if the new row version fits on the same page as the old 
one, no new index pointers need to be created.

I would suggest just testing how much additional overhead the new index 
incurs. It might be less expensive than you think.

You didn't mention how often the inserts happen, in other words, how 
fast you expect the table to grow. If the table is expected to grow 
orders of magnitude larger, you might want to partition the table by date.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com