Skip site navigation (1) Skip section navigation (2)

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

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Tim Landscheidt <tim(at)tim-landscheidt(dot)de>, pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert
Date: 2008-08-06 10:50:16
Message-ID: 489981E8.4010608@bluegap.ch (view raw or flat)
Thread:
Lists: pgsql-de-allgemein
Hi,

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


In response to

pgsql-de-allgemein by date

Next:From: udonoDate: 2008-08-10 13:27:11
Subject: Re: Erlaubte Zeichen in Datenbanknamen
Previous:From: Bernd HelmleDate: 2008-08-06 09:59:19
Subject: Re: Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group