Re: MERGE vs REPLACE

Josh Berkus wrote:
> So we thus have two seperate use cases.  The first, for bulk loading/ETL is 
> what MERGE fulfills rather neatly and for that full table locking is 
> perfectly OK, even desirable.  You really don't want to MERGE-load the 
> same table on two threads at once.  
> 
> The second case is for applications coded for MySQL; this is the REPLACE 
> case.  However, the most common MySQL applications doing this use full 
> table locking (MyISAM) anyway!  So, while full table locking wouldn't gain 
> them any performance over using two statements, it shouldn't lose them 
> anything they're used to having.

For any kind of efficiency, I assume MySQL REPLACE wants a unique index
in place, so practially everyone doing merge probably already has the
setup we need to avoid new non-index predicate locking code.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073