From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
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-05 15:20:33 |
Message-ID: | 20070205152033.GB4811@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 01, 2007 at 11:57:41PM -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 thought the main problem was locking. If you change the visibility of
an existing row, you have to update the index in a way that won't kill
concurrant scans, either by returning the row twice, or skipping it.
I think it hinges on what exactly falls under "visibility info". Maybe
with the page-at-a-time index scans, the problem is easier now.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-05 15:46:28 | Re: [pgsql-patches] Phantom Command IDs, updated patch |
Previous Message | Tom Lane | 2007-02-05 15:08:29 | Re: buildfarm fail "cardinal" |