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

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

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Markus Wanner <markus(at)bluegap(dot)ch>
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: Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert
Date: 2008-08-06 09:59:19
Message-ID: E9B2452BA65F74019D88EF25@imhotep.credativ.de (view raw or flat)
Thread:
Lists: pgsql-de-allgemein
--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

In response to

Responses

pgsql-de-allgemein by date

Next:From: Markus WannerDate: 2008-08-06 10:50:16
Subject: Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] RE: [pgsql-de-allgemein] In Funktion prüfen ob Zeile existiert
Previous:From: Bernd HelmleDate: 2008-08-06 09:32:31
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