Re: Performance Improvement for Unique Indexes

From: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance Improvement for Unique Indexes
Date: 2010-03-24 11:33:08
Message-ID: 9362e74e1003240433u5a120fd8r9972c22bee7c8507@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

There is no issue with that. Because we are taking a Dirty Snapshot to do
the comparison not the MVCC one. But this should be used only for unique
checks and not for the visibility checks.

Gokul.

On Wed, Mar 24, 2010 at 4:53 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Mar 24, 2010 at 7:17 AM, Gokulakannan Somasundaram
> <gokul007(at)gmail(dot)com> wrote:
> > While i was studying the unique index checks very closely, i realized
> > that what we need is to find out whether the tuple is deleted / not. So
> say
> > a tuple is deleted by a transaction, but it is not dead( because of some
> > long running transaction ), still we can mark a hint bit as deleted and
> it
> > will help the subsequent transactions doing the unique checks. As a
> matter
> > of fact, it will help the deferred_unique cases, since it will anyway
> check
> > the tuples twice, if there is a duplicate.
> > So we have one bit left in the Index Tuple that can be used as hint
> bit.
> > If we are ready to break the disk compatibility, then we can store the
> size
> > as a multiple of 8, and we will get three bits free. Any comments?
>
> I don't think this works. The postulated long-running transaction
> would also see the hint bit...
>
> ...Robert
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-03-24 11:52:10 Re: Re: [COMMITTERS] pgsql: Add connection messages for streaming replication.
Previous Message Fujii Masao 2010-03-24 11:30:50 Re: Re: [COMMITTERS] pgsql: Add connection messages for streaming replication.