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

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/

In response to

Responses

Browse pgsql-de-allgemein by date

  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