Re: Performance penalty of visibility info in indexes? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Performance penalty of visibility info in indexes?
Date
Msg-id 1170445286.3645.68.camel@silverbirch.site
Whole thread Raw
In response to Performance penalty of visibility info in indexes?  (Jim Nasby <decibel@decibel.org>)
Responses Re: Performance penalty of visibility info in indexes?  (Jim Nasby <decibel@decibel.org>)
List pgsql-hackers
On Thu, 2007-02-01 at 23:57 -0600, Jim Nasby wrote:
> Has anyone actually measured the performance overhead of storing  
> visibility info in indexes? I know the space overhead sounds  
> daunting, but even if it doubled the size of the index in many cases  
> that'd still be a huge win over having to scan the heap as well as  
> the index (esp. for things like count(*)). There would also be  
> overhead from having to update the old index tuple, but for the case  
> of updates you're likely to need that page for the new index tuple  
> anyway.
> 
> I know this wouldn't work for all cases, but ISTM there are many  
> cases where it would be a win.

It would prevent any optimization that sought to avoid inserting rows
into the index each time we perform an UPDATE. Improving UPDATE
performance seems more important than improving count(*), IMHO.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Referential Integrity and SHARE locks
Next
From: Tom Lane
Date:
Subject: Proposed adjustments in MaxTupleSize and toast thresholds