| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | josh(at)agliodbs(dot)com |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Petr Jelinek <pjmodos(at)seznam(dot)cz>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jd(at)commandprompt(dot)com |
| Subject: | Re: MERGE vs REPLACE |
| Date: | 2005-11-16 00:25:26 |
| Message-ID: | 200511160025.jAG0PQ012614@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-11-16 00:31:23 | Re: MERGE vs REPLACE |
| Previous Message | Bruce Momjian | 2005-11-16 00:22:44 | Re: MERGE vs REPLACE |