=3D=3D Wöchentlicher PostgreSQL Newsletter - December 17 2006 =3D=3D

Tom Lane und andere haben einen Entwurf für Operatorfamilien
zusammengestellt. Das Ergebnis dürften unter anderem sehr viel
einfachere Cross-Typ Vergleiche sein.

Das Internet Security Center (http://www.cisecurity.org/) wird einen
Satz Empfehlungen für ein sicheres PostgreSQL vorbereiten, der an die
US Regierung verteilt wird und auch für unsere Community verfügbar sein
wird. Für den Anfangsentwurf benötigt Josh Berkus einige Freiwillige
Hacker, die in den nächsten 3-4 Wochen für direkte Fragen vom Team zur
Verfügung stehen. Bitte maile an josh AT agliodbs . com wenn du
teilnehmen möchtest.


=3D=3D PostgreSQL Produkt Neuigkeiten =3D=3D

Orafce 2.0.0 erschienen.
http://pgfoundry.org/projects/orafce/

pgFouine 0.7.2 erschienen
http://pgfoundry.org/projects/pgfouine/

PgPool 3.1.2 erschienen.
http://pgfoundry.org/projects/pgpool/

Slony-I 1.2.2 erschienen.
http://pgfoundry.org/frs/?group_id=3D1000122

PostgreSQL 8.2 ist jetzt in fink unstable.
http://fink.sourceforge.net/


=3D=3D PostgreSQL Jobs im Dezember =3D=3D

http://archives.postgresql.org/pgsql-jobs/2006-12/threads.ph p


=3D=3D PostgreSQL Local =3D=3D

Gavin Sherry veranstaltet eine PostgreSQL Minikonferenz in Sydney am
Dienstag dem 16. Januar 2007.
http://lca2007.linux.org.au/Miniconfs/PostgreSQL Wenn du teilnehmen
möchtest, maile gavin AT alcove . com . au


=3D=3D PostgreSQL in den News =3D=3D

Planet PostgreSQL: http://www.planetpostgresql.org/

General Bits, Archive und gelegentliche News Artikel:
http://www.varlena.com/GeneralBits/

Dieser wöchentliche PostgreSQL Newsletter wurde erstellt von David
Fetter, Devrim GUNDUZ und Dave Page.


=3D=3D Angewandte Patches =3D=3D

Tom Lane checkte ein:

- Fügte ein paramtypmod Feld zu den Param Nodes hinzu. Das ist Ballast
für Parameter die externe Werte repräsentieren, da die API, die
derartige Werte enthält, nur type aber nicht typmod spezifiziert. Aber
für PARAM_SUBLINK Parameter ist es nützlich, die typmod Information der
Sublink Ausgabe Spalte mitzuführen. Dies ist eine sauberere Lösung für
die kürzlich gemeldeten 'could not find pathkey item to sort' und
'failed to find unique expression in subplan tlist' Fehler als mein
kürzlich eingecheckter 8.2-compatibler Patch. Ausserdem werden wir
vielleicht eines Tages typmods für externe Parameter unterstützen.

- Planer Fehler repariert um für einen entkoppelten Outer Join (ein
Join, dessen Join Bedingung keine Variablen von ausserhalb nutzt) einen
korrekten Plan zu erstellen, wenn ein "buschiger" Plan erstellt werden
soll. Die normale Heuristik, für Joins ohne Join Bedingung muss für
diesen Fall übergangen werden. Dieses Problem ist neu in 8.2, da wir
früher den Outer Join jedesmal erzwungen habe. Von Teodor.

- Füge einige inkorrekt entfernte #include wieder ein. Von Mark
Kirkwood.

- --with-ldap baut auf Unixware. Von Olivier Prenant.

- Packe JST zurück in die Liste der vorgegebenen Abkürzungen; wurde in
einem unerklärbaren Moment von Gedächtnisschwund entfernt.

- Repariere einige Planer Fehler, die von Arjen van der Meijden
gefunden wurden. Allesamt neu in der 8.2 Logik verbunden mit
Indizierbarkeit von ScalarArrayOpExpr (IN-clauses) oder der
Amortisation von Indexscan Kosten über wiederholte Indexscans innerhalb
eines Nested Loops. Im Detail: Repariere einige Logikfehler in der
Bewertung von mehrfachen Scans verursacht von ScalarArrayOpExpr
Vergleichen.

- Füge einen kleinen Kostenbetrag für Bitmap Index Scans ein um die
Kosten für die Manipulation der Bitmap selbst zu beachten; dies ist
vorwiegend dafür gedacht, die Kosten für einen einfachen Indexscan zum
Holen einfacher Tuples von den Kosten eines Bitmap Scans zu
unterscheiden.

- Ebenfalls wurde eine Per-Indexscan-Start per CPU Komponente
eingefügt; während frühere Versionen eindeutig zu pessimistisch über
die Kosten von wiederholten Indexscans waren, erlaubte der originale
8.2 Code, das die Kosten für einen Indexscan effektiv gegen Null gehen,
wenn er oft genug wiederholt wird. Das war eindeutig zu optimistisch.

- Richte etwas Aufmerksamkeit auf die Index Korrelation wenn die
erwarteten Kosten für einen nested Loop in einem inneren Indexscan
berechnet werden; dies ist signifikant, wenn der Plan mehrfach Tuples
in einem Durchlauf holt, denn eine hohe Korrelation meint das diese
Tuples in der gleichen oder naheliegenden Heap Page liegen.


Bruce Momjian checkte ein:

- FAQ Eintrag hinzugefügt um auf die Benutzung von COALESCE() zum
Verknüpfen von möglichen NULL Werten hinzuweisen.

- Entferne leere Zeilen in der HTML FAQ.

- Dokumentiere das log_line_prefix %t nicht die Zeitzone unter Win32
ausgibt.

- =C4ndere TODO von "Lasse EXPLAIN ANALYZE schlechte Optimierer
Schätzungen hervorheben" nach "EXPLAIN ANALYZE soll NOTICE Nachrichten
ausgeben, wenn die erwartete und die aktuelle Zeilenzahl mit einer
bestimmten Prozentzahl abweicht".

- Zu TODO hinzugefügt: Dokumentiere Fragen für SGML und XML:
http://archives.postgresql.org/pgsql-docs/2006-12/msg00033.p hp


Peter Eisentraut checkte die folgenden Patches ein:

- Erstelle einzelne Ziele für die druckbare Dokumentation in A4 und US
Letter Papier Formaten.

- Erlaube vergrößerte CPPFLAGs auf der Kommandozeile. Dies
funktionierte im Allgemeinen, aber einige Plattform Templates haben
dies ohne Nachfragen überschrieben.

- Aktiviere WIN32_STACK_RLIMIT Override nur auf Plattformen, wo dies
notwendig ist.

- Entferne Windows port^W^Wobsolete Template Datei.


Andrew Dunstan checkte die folgenden Patches ein:

- Aktiviere \timing Ausgaben für \copy Befehle.


=3D=3D Abgelehnte Patches (bis jetzt) =3D=3D

Niemand wurde diese Woche enttäuscht :-)

--
Andreas 'ads' Scherbaum

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hallo zusammen,

weiss zufaellig jemand hier, was aus dem Plan geworden ist,
Felder innerhalb eines Records (PL/PGSQL) auch numerisch
anzusprechen?
Damit also sowas wie das hier moeglich wird:

foo=rec.(1)||rec.(2);
oder
bar=rec.(f);
f=f+1;
bar=bar||rec.(f);

Es gab da mal einen Patch, der dann wohl nach langen
Diskussionen wieder in der Versenkung verschwand.

Hat jemand Infos ?

Viele Gruesse
Ralf


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Hallo Ralf,
habe auch keine wiklich aktuellen Infos, aber anbei ein Auszug einer Mail
von mir zu diesem Thema, die den Stand gegen Ende Juli 2006 wiederspiegel=
t.
Wäre wirklich schön von dieser Front mal von updates zu hören...

Tobias Bußmann <t.bussmann [at] gmx.net> wrote:
> Just to give you a short impression of what the patch is for and what
> has happened to it:
>
> The patch made it possible to analyze the internal structure of the
> currently a bit half-hearted implemented datatype 'RECORD' as it is
> used for example in trigger procedures in PL/pgSQL. You could get the
> count and names of the fields, their datatypes etc. With this it is -
> amongst others - possible to to write generic trigger procedures
> which e.g. loop through all the fields of a NEW-record to set all
> empty VarChars to NULL and trim them otherwise. Such a generic
> trigger procedure could be bound to all tables which need such a
> behavior. Currently without such a functionality you have to write
> individual trigger procedures for every single table enumerating the
> individual field names (or you could use an other Procedural Language
> for that task)
>
> The Patch was developed from Titus von Boxberg and discussed in July
> 05 at the pgsql-patches list [1]. It was accepted and put to the
> patches_hold for inclusion in 8.2. This was the time I posted the
> request to the backports project. In May / June 06 the patch was
> adopted and applied to the current HEAD cvs [2]. After this it was
> rejected and reverted by Tom Lane because of it (supposed) bad
> quality [3]. The author later investigated and wrote a posting
> stating that the patch is already running fine in different
> environments and has a good quality [4]. Currently we have it as a
> entry in the ToDo list [5].
[...]
> [1] http://archives.postgresql.org/pgsql-patches/2005-07/msg0060 3.php
> [2] http://archives.postgresql.org/pgsql-patches/2006-05/msg0029 5.php
> [3] http://archives.postgresql.org/pgsql-patches/2006-05/msg0030 2.php
> [4] http://archives.postgresql.org/pgsql-patches/2006-06/msg0003 1.php
> [5] http://www.postgresql.org/docs/faqs.TODO.html (in the middle of
> the page at SQL Commands - Server-Side Languages - PL/pgSQL)

Gruß
Tobias

Ralf Burger <ralf [at] Burger.AG> wrote:
> Hallo zusammen,
>
> weiss zufaellig jemand hier, was aus dem Plan geworden ist,
> Felder innerhalb eines Records (PL/PGSQL) auch numerisch
> anzusprechen?
> Damit also sowas wie das hier moeglich wird:
>
> foo=3Drec.(1)||rec.(2);
> oder
> bar=3Drec.(f);
> f=3Df+1;
> bar=3Dbar||rec.(f);
>
> Es gab da mal einen Patch, der dann wohl nach langen
> Diskussionen wieder in der Versenkung verschwand.
>
> Hat jemand Infos ?
>
> Viele Gruesse
> Ralf


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Hallo Tobias,

ja, so weit hatte ich das am Rande mitbekommen.
Wer kann nun was tun, damit es weitergeht?
Denn die ToDo-List verweist ja auch nur auf Mitte 2006.

Ich frage aus dem Grund, weil ich eine ziemlich haessliche
Funktionssammlung geschrieben habe, die aus mehreren
Records einer Table oder einen Union nur die sich veraendernden
Werte ausfiltern kann. (Was sehr hilfreich bei einer Fehlersuche
oder bei einer Historyauswertung ist)
Aber durch die Beschraenkungen sind zahlreiche Limits vorhanden.
Denn man kann die Funktionen nicht wirklich dynamisieren und
heraus kommt eine haessliche und riesengrosse Konstruktion....

Das wuerde ich gerne optimieren koennen.

Viele Gruesse
Ralf







>Hallo Ralf,
>habe auch keine wiklich aktuellen Infos, aber anbei ein Auszug einer Mai=
l
>von mir zu diesem Thema, die den Stand gegen Ende Juli 2006 wiederspiege=
lt.
>Wäre wirklich schön von dieser Front mal von updates zu hören...
>
>Tobias Bußmann <t.bussmann [at] gmx.net> wrote:
>
>
>>Just to give you a short impression of what the patch is for and what
>>has happened to it:
>>
>>The patch made it possible to analyze the internal structure of the
>>currently a bit half-hearted implemented datatype 'RECORD' as it is
>>used for example in trigger procedures in PL/pgSQL. You could get the
>>count and names of the fields, their datatypes etc. With this it is -
>>amongst others - possible to to write generic trigger procedures
>>which e.g. loop through all the fields of a NEW-record to set all
>>empty VarChars to NULL and trim them otherwise. Such a generic
>>trigger procedure could be bound to all tables which need such a
>>behavior. Currently without such a functionality you have to write
>>individual trigger procedures for every single table enumerating the
>>individual field names (or you could use an other Procedural Language
>>for that task)
>>
>>The Patch was developed from Titus von Boxberg and discussed in July
>>05 at the pgsql-patches list [1]. It was accepted and put to the
>>patches_hold for inclusion in 8.2. This was the time I posted the
>>request to the backports project. In May / June 06 the patch was
>>adopted and applied to the current HEAD cvs [2]. After this it was
>>rejected and reverted by Tom Lane because of it (supposed) bad
>>quality [3]. The author later investigated and wrote a posting
>>stating that the patch is already running fine in different
>>environments and has a good quality [4]. Currently we have it as a
>>entry in the ToDo list [5].
>>
>>
>[...]
>
>
>>[1] http://archives.postgresql.org/pgsql-patches/2005-07/msg0060 3.php
>>[2] http://archives.postgresql.org/pgsql-patches/2006-05/msg0029 5.php
>>[3] http://archives.postgresql.org/pgsql-patches/2006-05/msg0030 2.php
>>[4] http://archives.postgresql.org/pgsql-patches/2006-06/msg0003 1.php
>>[5] http://www.postgresql.org/docs/faqs.TODO.html (in the middle of
>>the page at SQL Commands - Server-Side Languages - PL/pgSQL)
>>
>>
>
>Gruß
>Tobias
>
>Ralf Burger <ralf [at] Burger.AG> wrote:
>
>
>>Hallo zusammen,
>>
>>weiss zufaellig jemand hier, was aus dem Plan geworden ist,
>>Felder innerhalb eines Records (PL/PGSQL) auch numerisch
>>anzusprechen?
>>Damit also sowas wie das hier moeglich wird:
>>
>> foo=3Drec.(1)||rec.(2);
>>oder
>> bar=3Drec.(f);
>> f=3Df+1;
>> bar=3Dbar||rec.(f);
>>
>>Es gab da mal einen Patch, der dann wohl nach langen
>>Diskussionen wieder in der Versenkung verschwand.
>>
>>Hat jemand Infos ?
>>
>>Viele Gruesse
>>Ralf
>>
>>


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

hi bernd,

>Alles was man da lesen kann ist, das es "irgendwie funktioniert", aber
>Titus von Boxberg geht auf einzelne Punkte die Tom erwähnt gar nicht e=
rst ein.
>"Es funktioniert" ist kein Argument (Mein Updatable Views Code tut auch,=

>aber halt nur, wenn bestimmte Randbereiche nicht angefasst werden).
>
>Offensichtlich mangelt es der bestehenden Implementierung an einem "umfa=
ssenderen"
>Design, und Tom's Einwände zielen auf architektonische Probleme innerh=
alb von
>plpgsql ab, die der Code anscheinend auszunutzen versucht.
>
>
>
so weit, so gut (oder schlecht) ;-))

ich hab den patch nicht ausprobiert, weil ich nicht weiss, ob er mit
der aktuellen version ueberhaupt laufen wuerde.
und es waere auch unsinn, wenn ich dann von jedem user der library
verlangen muesste, dass er postgres patcht.

stellt sich die frage:
ist es notwendig, das ganze neu zu machen?
macht noch irgendwer damit weiter ?

waer ja nun unfug, wenn man es doppelt machen wuerde, nicht wahr ?

viele gruesse
ralf


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Ralf Burger <ralf [at] Burger.AG> schrieb:
> Ich frage aus dem Grund, weil ich eine ziemlich haessliche
> Funktionssammlung geschrieben habe, die aus mehreren
> Records einer Table oder einen Union nur die sich veraendernden

ich erinner mich, das hatten wir hier mal, gell?

Btw.: kannst Du das TOFU lassen?


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

Ralf Burger <ralf [at] Burger.AG> schrieb:
> stellt sich die frage:
> ist es notwendig, das ganze neu zu machen?
> macht noch irgendwer damit weiter ?

Neu vielleicht nicht, aber was spräche dagegen, mit dem Macher des
Patches Kontakt aufzunehmen? Ich halte diese Idee durchaus für sinnvoll=
..
Vielleicht wartet der Macher des Patches einfach nur auf ein Rücksignal=
,
vielleicht fühlt er sich von Tom ausgegrenzt bzw. nicht ernst genommen?
Wer weiß. Ich halte Tom für absolut genial, aber es mag sein, daß e=
r
manchmal etwas *rau* 'rüberkommt. Da wäre ein 'hey, laß uns das doc=
h
zusammen weiter machen' vielleicht hilfreich. I don't know...
Jedenfalls, naja, Bernd und Susanne haben u.a. ja auch schon heftige
Kritik bekommen, und ich glaube, Bernd hat es richtig verstanden und
macht weiter, so wie auch Susanne.

>
> waer ja nun unfug, wenn man es doppelt machen wuerde, nicht wahr ?

Ja, in der Tat.

--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster