The obvious advantages are
a) Avoidance of one read lock per page
b) One Big write lock instead of multiple write locks.
But as you said, i will do some initial profiling and get back.
On 9/20/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Gokulakannan Somsundaram wrote:
> > Hi,
> > The Current architecture of Updates in PostgreSQL is
> > 1) Make a select query out of update. It involves a READ
> > 2) Get the tupleid
> > 3) Goto the buffer containing the tupleid, make a BUFFER_EXCLUSIVE lock
> > 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
> > made before re-inserting it. So there will be a list of Heap tuples
> > in memory for each page getting updated. these tuples will be inserted
> > the deletion part of update is done. This is just a rough design. I may
> > 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