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
