| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: MERGE Specification |
| Date: | 2008-04-22 18:17:00 |
| Message-ID: | 87iqy9u543.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> As I've said elsewhere, we could have it lock each row, its just more
> overhead if we do and not necessary at all for bulk data merging.
>
> I'll presume we want locking as an option, unless people say otherwise.
It's not so simple. If you look for a row to merge into and don't find one
there's no row to lock. What unique constraints do is hold the lock on the
index page where the entry would have to be added.
That's the trick that plpgsql cannot implement. That's why users are forced to
loop and retry until they manage to do an update successfully or insert
successfully.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2008-04-22 18:17:20 | Re: port/thread.c and pthreads |
| Previous Message | Decibel! | 2008-04-22 18:12:03 | Re: pgstat SRF? |