Re: Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert

--On Mittwoch, August 06, 2008 11:10:15 +0200 Markus Wanner
<markus(at)bluegap(dot)ch> wrote:

> Hi,
>
> Bernd Helmle wrote:
>> In PostgreSQL sollte es eigentlich auf Datenbankebene keine Unterschiede
>> zu beiden geben, geschwindigkeitsmäßig.
>
> Das sehe ich anders: waehrend Du mit SELECT FOR UPDATE ein tuple
> 'lockst', auch wenn dies in der gossen Mehrheit der Faelle nicht noetig
> waere (pessimistic locking: um sicher zu gehen, dass nix schief geht,
> sperrst Du lieber zuviel als zu wenig) entdeckt der SERIALIZABLE
> ISOLATION LEVEL Konflikte auch ohne diese Locks (optimistic locking: nur
> die absolut notwendigen locks werden gesperrt).
>
> Solange also nur wenige Konflikte wegen Nebenlaeufigkeit zu erwarten sind
> - was fuer die allermeisten Applikationen zutreffen duerft - dann ist der
> SERIALIZABLE mode also performanter.

Rowlocks in PostgreSQL werden über die XID realisiert und direkt im Tuple
Header gespeichert. Das alles ist sehr leichtfüßig, auch im SERIALIZABLE
Mode funktioniert das genauso, nur das er halt in dem Moment net sperrt
sondern einen Transaktionsfehler wirft, sollte XMAX bereits anderweitig
modifiziert worden sein. Die Unterschiede betreffen hier hauptsächlich die
Art und Weise wie Snapshots erstellt werden, PostgreSQL ist hier sehr
intelligent implementiert, aber tatsächliche Performanceunterschiede zw.
READ COMMITTED und SERIALIZABLE ergeben sich wohl in der Art und Weise wie
die Anwendung mit beiden umzugehen hat. Rein von der Datenbankengine
gesehen müsste SERIALIZABLE sogar schneller sein, da es weniger Snapshots
erzeugen muß!

Im übrigen bin ich absolut deiner Meinung, und Exceptions sind nichts
schlimmes.

--
Thanks

Bernd