> > 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.
Nanana, das ist jetzt aber frei fabuliert.
Die Doku sagt:
A block containing an EXCEPTION clause is significantly more expensive
to enter and exit than a block without one.
Therefore, don't use EXCEPTION without need.
Daß da ein Memory Leak in der Datenbank ist, kann ich dem nicht entnehmen ...
Es ist mehr eine Performance-Angelegenheit.
Liebe Grüße,
Laurenz Albe
--
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