Improving the Performance of Full Table Updates

Поиск
Список
Период
Сортировка
От Gokulakannan Somsundaram
Тема Improving the Performance of Full Table Updates
Дата
Msg-id 9362e74e0709200011j7b155bb9p74912a450c5b2f84@mail.gmail.com
обсуждение исходный текст
Ответы Re: Improving the Performance of Full Table Updates  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Improving the Performance of Full Table Updates  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,<br />   The Current architecture of Updates in PostgreSQL is <br />1) Make a select query out of update. It
involvesa READ lock/BUFFER_SHARE<br />2) Get the tupleid<br />3) Goto the buffer containing the tupleid, make a
BUFFER_EXCLUSIVElock on it <br />4) update it<br />5) Repeat the above process for subsequent rows<br /><br />I propose
tochange this row-by-row approach, when it is a full table update. I plan to send a extra flag(which will be set for
Fulltable Deletes/Updates). this would make the access method directly acquire the exclusive lock and update the
existingrecord. <br /><br />For Deletes this is simple. But for updates, the projection tuple has to be made before
re-insertingit. So there will be a list of Heap tuples stored in memory for each page getting updated. these tuples
willbe inserted after the deletion part of update is done. This is just a rough design. I may get involved in a detail
designonce i get a nod from the mailing list community. <br /><br />Thanks,<br />Gokul.<br /> 

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: like/ilike improvements
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Improving the Performance of Full Table Updates