Proposal for Performance improvement for unique checks - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Proposal for Performance improvement for unique checks
Date
Msg-id 9362e74e1003270011i376e1647u847535aa1421ff33@mail.gmail.com
Whole thread Raw
Responses Re: Proposal for Performance improvement for unique checks
List pgsql-hackers
I don't think this should involve much code change. But no-one interested????

On Sat, Mar 27, 2010 at 2:23 AM, Gokulakannan Somasundaram <gokul007@gmail.com> wrote:
Hi,
   Since we insert a new entry into the index for every update that's being made into the table, we inevitably make a unique check against the older version of the newly inserted row, even when the values are not updated. Of course i am talking about non-HOT updates. (We will not go to the index for HOT updates)

a) The page which contains the index entry is Exclusively locked
b) We go ahead and visit the heap page for its HeapTupleSatisfiesDirty.

If we have the information of the old tuple(its tuple-id) after a heap update, during the index insert, we can avoid the uniqueness check for this tuple,as we know for sure that tuple won't satisfy the visibility criteria. If the table has 'n' unique indexes it avoids 'n' heap tuple lookups, also increasing the concurrency in the btree, as the write lock duration is reduced.

Any comments?

Thanks,
Gokul.

pgsql-hackers by date:

Previous
From: Joseph Adams
Date:
Subject: Re: Proposal: access control jails (and introduction as aspiring GSoC student)
Next
From: Peter Eisentraut
Date:
Subject: changes to documentation build