From: | Alvar Freude <alvar(at)a-blast(dot)org> |
---|---|
To: | pgsql-de-allgemein(at)postgresql(dot)org |
Cc: | Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org> |
Subject: | Re: c't Datenbank-Contest; PL/pgSQL, PL/perl, PL/parrot |
Date: | 2005-10-21 07:13:06 |
Message-ID: | 59EA3F96FB275FAF0DAE1F51@Chefkoch.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-de-allgemein |
Hallo Andreas,
-- Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org> wrote:
> 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.
OK, verstehe!
Ich hatte mal bei ein paar relativ einfachen Sachen den Unterschied
zwischen PL/SQL und PL/pgSQL gemessen, und da war pgSQL deutlich
schneller. Das deckt sich dann ja damit.
> 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.
das klingt einleuchtend ;-)
Klar, wenn man irgendwelche größeren Berechnungs-Orgien und zum
Beispiel Hash- und Stringoperationen durchführt, dann ist das mit
SQL-Sachen nicht mehr so einfach.
BTW: Interessant wäre in dem Zusammenhang, wenn Perl sich globalen,
zwischen allen Prozessen gesharten Speicher holen bzw. nutzen könnte.
Aber das mache ich lieber auf Apache-Seite (beim Startup) ;-)
> 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>
klar, an sauber geschriebenes C kommt nix heran.
> 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 :-).
hehe ;-)
Ja, dieses Dell-Zeug ist schon ziemlich grausam. Sowohl das SQL aber vor
allem der PHP/ASP/JSP-Zeug; solch schlechten Code sieht man selten, wobei
man auch hier sieht: bei ASP haben sie sich am meisten Mühe gegeben, wie
beim MS SQL-Server.
Ciao
Alvar
--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Enrico Weigelt | 2005-10-21 07:36:02 | Re: c't Datenbank-Contest; PL/pgSQL, PL/perl, PL/parrot |
Previous Message | Andreas Seltenreich | 2005-10-21 04:03:30 | Re: c't Datenbank-Contest; PL/pgSQL, PL/perl, PL/parrot |