Gokulakannan Somsundaram wrote: > Hi, > The Current architecture of Updates in PostgreSQL is > 1) Make a select query out of update. It involves a READ lock/BUFFER_SHARE > 2) Get the tupleid > 3) Goto the buffer containing the tupleid, make a BUFFER_EXCLUSIVE lock on > it > 4) update it > 5) Repeat the above process for subsequent rows > > I propose to change this row-by-row approach, when it is a full table > update. I plan to send a extra flag(which will be set for Full table > Deletes/Updates). this would make the access method directly acquire the > exclusive lock and update the existing record. > > For Deletes this is simple. But for updates, the projection tuple has to be > made before re-inserting it. So there will be a list of Heap tuples stored > in memory for each page getting updated. these tuples will be inserted after > the deletion part of update is done. This is just a rough design. I may get > involved in a detail design once i get a nod from the mailing list > community.
I doubt the locking overhead is that significant. Have you done any profiling to show that it's worth it? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
