Proposal for Performance improvement for unique checks

Поиск
Список
Период
Сортировка
От Gokulakannan Somasundaram
Тема Proposal for Performance improvement for unique checks
Дата
Msg-id 9362e74e1003270011i376e1647u847535aa1421ff33@mail.gmail.com
обсуждение исходный текст
Ответы Re: Proposal for Performance improvement for unique checks  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
I don't think this should involve much code change. But no-one interested????<br /><br /><div class="gmail_quote">On
Sat,Mar 27, 2010 at 2:23 AM, Gokulakannan Somasundaram <span dir="ltr"><<a
href="mailto:gokul007@gmail.com">gokul007@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br />   Since we
inserta new entry into the index for every update that's being made into the table, we inevitably make a unique check
againstthe older version of the newly inserted row, even when the values are not updated. Of course i am talking about
non-HOTupdates. (We will not go to the index for HOT updates)<br /><br />a) The page which contains the index entry is
Exclusivelylocked<br />b) We go ahead and visit the heap page for its HeapTupleSatisfiesDirty.<br /><br />If we have
theinformation of the old tuple(its tuple-id) after a heap update, during the index insert, we can avoid the uniqueness
checkfor this tuple,as we know for sure that tuple won't satisfy the visibility criteria. If the table has 'n' unique
indexesit avoids 'n' heap tuple lookups, also increasing the concurrency in the btree, as the write lock duration is
reduced.<br/><br />Any comments?<br /><br />Thanks,<br />Gokul.<br /></blockquote></div><br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joseph Adams
Дата:
Сообщение: Re: Proposal: access control jails (and introduction as aspiring GSoC student)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: changes to documentation build