| From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | Tim Landscheidt <tim(at)tim-landscheidt(dot)de>, pgsql-de-allgemein(at)postgresql(dot)org |
| Subject: | Re: Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert |
| Date: | 2008-08-06 08:24:24 |
| Message-ID: | ED1C9BE5FFFADE8089B5F580@imhotep.credativ.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-de-allgemein |
--On Mittwoch, August 06, 2008 10:09:24 +0200 Markus Wanner
<markus(at)bluegap(dot)ch> wrote:
> Im READ COMMITTED mode waere die Alternative noch, mit SELECT .. FOR
> UPDATE zu testen, ob's solch ein Tuple schon gibt. Wenn ja, ein UPDATE
> drauf, wenn nein den INSERT. Weniger performant als SERIALIZABLE
> (pessimistic locking), aber Du sparst Dir damit evtl. den retry-loop in
> der App (zumindest wenn Du auch noch darauf achtest, keine deadlocks zu
> provozieren).
In PostgreSQL sollte es eigentlich auf Datenbankebene keine Unterschiede zu
beiden geben, geschwindigkeitsmäßig. Ich weiß, das SAVEPOINTs Shared
Memory "fressen", aber "fressen" ist relativ. Wer sowas tausendfach in
einer Schleife macht, muß damit rechnen, irgendwann an die Grenzen der
Ressourcen zu stoßen. Dies innerhalb der Datenbank zu kapseln ist deutlich
schöner als mit fehlerträchtigen Retry-Loops der Applikation zu spielen.
--
Thanks
Bernd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bernd Helmle | 2008-08-06 08:26:43 | Re: RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert |
| Previous Message | Markus Wanner | 2008-08-06 08:09:24 | Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert |