<markus@bluegap.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
--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
No comments:
Post a Comment