Improving the Performance of Full Table Updates

From: "Gokulakannan Somsundaram" <gokul007(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Improving the Performance of Full Table Updates
Date: 2007-09-20 07:11:20
Message-ID: 9362e74e0709200011j7b155bb9p74912a450c5b2f84@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Thanks,
Gokul.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-09-20 07:20:06 Re: Improving the Performance of Full Table Updates
Previous Message Andrew Dunstan 2007-09-20 00:14:56 Re: like/ilike improvements