Best practices: MERGE

From: David Fetter <david(at)fetter(dot)org>
To: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Best practices: MERGE
Date: 2005-03-08 03:34:49
Message-ID: 20050308033449.GC25775@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Folks,

Although the SQL:2003 command MERGE has not yet been implemented in
PostgreSQL, I'm guessing that there are best practices for how to
implement the MERGE functionality.

To recap, MERGE means (roughly) INSERT the tuple if no tuple matches
certain criteria, otherwise UPDATE using similar criteria.

The "correct" solution, as far as I can tell, is to acquire a LOCK on
the table IN SHARE MODE at the beginning of the transaction, but this
has (at least for many applications) unacceptable performance
characteristics. Accepting that there is a slight risk of a race
condition when *not* locking the table at the beginning of the
transaction, what procedure minimizes this risk and recovers well from
said race condition, should it occur?

TIA for any hints, tips or pointers on this :)

Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-03-08 03:45:19 Re: Best practices: MERGE
Previous Message Greg Stark 2005-03-08 02:18:57 Re: Cost of XLogInsert CRC calculations

Browse pgsql-patches by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-03-08 03:45:19 Re: Best practices: MERGE
Previous Message Mark Kirkwood 2005-03-08 01:36:53 Re: Display Pg buffer cache (WIP)