Improving the Performance of Full Table Updates - Mailing list pgsql-hackers

From Gokulakannan Somsundaram
Subject Improving the Performance of Full Table Updates
Date
Msg-id 9362e74e0709200011j7b155bb9p74912a450c5b2f84@mail.gmail.com
Whole thread Raw
Responses Re: Improving the Performance of Full Table Updates
Re: Improving the Performance of Full Table Updates
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: like/ilike improvements
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: Improving the Performance of Full Table Updates