Re: MERGE vs REPLACE

From: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Dann Corbit <DCorbit(at)connx(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Rick Gigger <rick(at)alpinenetworking(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <systemguards(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: MERGE vs REPLACE
Date: 2005-11-17 09:59:39
Message-ID: 1132221579.10890.308.camel@coppola.muc.ecircle.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Well, from my point of view it is more than delete and insert. That I
can do right now with existing infrastructure. The problem I try to
solve is something along: a bunch of clients try to update a count, and
ONE of them must initialize the count if it does not exist... this can't
be done with current infrastructure without race conditions.
Our current solution is to initialize all the possible counts
beforehand, but that suboptimal as only a few of them will actually have
data coming in later...
And of course the import problem... we can have multiple concurrent
imports, which must insert just once per some unique criteria, and
update if the record is already there, and all this in a batch. This is
also not possible without race conditions or aggressive locking.
So for me the atomic, consistent and without performance penalties
"update_or_insert_based_on_unique_criteria" does have a value, and
that's coming exactly from the locking of the unique index which
eliminates the race condition from this operation. I don't care about
syntax sugar, just about things I could do more efficiently if this
mechanism were in place...

Cheers,
Csaba.

On Wed, 2005-11-16 at 20:33, Martijn van Oosterhout wrote:
> On Wed, Nov 16, 2005 at 11:06:15AM -0800, Dann Corbit wrote:
> > > -----Original Message-----
> > > From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> > > owner(at)postgresql(dot)org] On Behalf Of Simon Riggs
> > > > Conceptually, a MERGE statement is just a long string of INSERTs and
> > > > UPDATEs in the same transaction and I think we should treat it as
> > > > such.
> >
> > Merge could also be considered as a long string of deletes and inserts.
> > I guess that deleting those records that already exist and then
> > inserting all of the records is faster because it could be done like a
> > single join to perform the delete and then a single batch insert.
>
> And for us it makes no difference because in MVCC, UPDATE == DELETE +
> INSERT. IMHO it's just a nice construct to specify UPDATEs and INSERTs
> in the same statement.
>
> Have a nice day,

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas DCP SD 2005-11-17 09:59:50 Re: tablespaces and non-empty directories
Previous Message Andreas Pflug 2005-11-17 09:57:01 Re: Numeric 508 datatype