Re: c't Datenbank-Contest; PL/pgSQL, PL/perl, PL/parrot

Alvar Freude schrob:

> Hat jemand Erfahrungswerte, was die Performance von PL/pgSQL vs. PL/perl
> anbelangt?

Nur ein paar bescheidene.

> Wenn ich das richtig verstanden habe, wird PL/perl-Code ja beim erstellen
> compiliert und dann im Bytecode nur noch die Unterfunktion aufgerufen.
> Wie ist das bei PL/pgSQL

Geparst wird hier ebenfalls nur beim ersten Funktionsaufruf. PL/pgSQL
bedient sich zum Parsen und Ausführen ausgiebig vom restlichen
PostgreSQL-Code, was es besonders leichtgewichtig macht. Stichwort:
working set.

> und wie ist der Performance-Unterschied?

Depends.

Wenn man SQL einfach nur zur Turing-Vollständigkeit nachrüsten will,
ist PL/pgSQL sicherlich eine gute Wahl, da es mit den PostgreSQL
bekannten Datentypen nativ umgehen kann. Wenn es um nichttriviales
verwursten von Daten über PostgreSQLs eingebauten Funktionsumfang
hinaus geht, wird PL/pgSQL jedoch kaum an PL/Perls Performance
herankommen.

Als unakzeptablen Flaschenhals hab' ich stored procedures allerdings
nur beim Number-Crunching erlebt. Und da war der Ausweg nicht etwa
eine andere PL, sondern:
<http://www.postgresql.org/docs/8.0/static/xfunc-c.html>

> Es gibt ja wohl auch ein PL/parrot, das habe ich auf die Schnelle aber
> nicht gefunden; da würde mich natürlich auch das gleiche interessieren
> und vor allem, ob da JIT läuft ... :)

IMHO genügt es, daß dieser Dell-Benchmark im Alphastadium ist; da muß
man der c't-Redaktion nicht noch eine PL/Parrot-Alpha aufdrücken :-).

Gruß
Andreas
--