Bernd Helmle wrote:
> 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.
Genau.
> 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.
Richtig.
Die READ COMMITTED Anwendung sollte(!) aber haeufiger SELECT FOR UPDATE
nutzen, um korrekt zu locken. Dies modifiziert ebenfalls den tuple
header und setzt xmax schon mal auf die aktuelle xid, um das Tuple zu
sperren. Dies wird als pessimistic locking bezeichnet, weil dies die
Erwartung eines Konflikts impliziert.
Wenn aber kein Konflikt vorliegt dann stellt das ein unnoetiger Schritt
dar, den Du Dir bei SERIALIZABLE meist sparen kannst. Man beachte, dass
dieser Schritt ggf. sogar zu Diskzugriffen fuehrt, die in dem Fall
eigentlich ebenso unnoetig sind.
> Rein von der Datenbankengine gesehen müsste SERIALIZABLE sogar schneller
> sein, da es weniger Snapshots erzeugen muß!
Verglichen mit READ COMMITTED ist SERIALIZABLE schneller, wenn wenige
Konflikte zu erwarten sind - weniger wegen der Snapshots, sondern viel
eher durch optimistisches Locking. Je haeufiger Konflikte auftreten,
desto eher wird READ COMMITTED auf- oder sogar ueberholen.
Gruesse
Markus Wanner
--
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