From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Jim Nasby" <decibel(at)decibel(dot)org> |
Cc: | "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance penalty of visibility info in indexes? |
Date: | 2007-02-02 19:41:26 |
Message-ID: | 1170445286.3645.68.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-02 20:11:55 | Proposed adjustments in MaxTupleSize and toast thresholds |
Previous Message | Simon Riggs | 2007-02-02 19:30:01 | Re: Referential Integrity and SHARE locks |