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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
