[heise News]: Zum Testen frei: Erste Beta von PostgreSQL 8.4

Hi,


soweit ich das überblicke, bist du der einzige mit dem Problem.

Freundlioche Grüße
hkocam

im moment … wir wissen ja auch nicht, wieviele tatsaechlich ernsthaft testen …

andere teile der anwendung funktionieren ja auch wunderbar mit 8.4 - und bei kleinen datenmengen ists “gefuehlt” ja eh wurst was der planner sagt.

offensichtlich scheint sich niemand wirklich für das Problem zu interessieren …

das wars dann wohl mit “der fortschrittlichsten DB” :slight_smile:

Hi,

du lieferst ja auch nicht was gefordert ist, ich zitiere (http://archives.postgresql.org/pgsql-hackers/2009-04/msg01077.php):

Date: Tue, 21 Apr 2009 09:58:11 -0400
From: Alvaro Herrera <> alvherre@commandprompt.com> >
Can you please post the table definitions? “pg_dump -t” output would be
best.


Alvaro Herrera > PostgreSQL Company, Since 1997, PostgreSQL Support, PostgreSQL Consulting and PostgreSQL Development - - Home
The PostgreSQL Company - Command Prompt, Inc.

DU hast darauf nicht reagiert.
Wenn du mit den Anforderungen zur Untersuchung des Problems ein Problem hast, solltest du das auf der ML mitteilen und nicht hier, die wenigsten PG-Hacker(ausser vieleicht Peter Eisentraut) lesen pg-forum.de.

Freundliche Grüße
hkocam

doch die habe ich verschickt, an genau ihn und weitere … ich schicke das modell nicht in die unkontrollierbare adresse einer ML …

auch habe ich persoenlich bei diesem tom nachgefragt, ob er meine anfrage vernommen hat - keine antwort .

hmm - pech

(p.s. ich hab das hier nur gepostet - weil ich einen drang - mich mitteilen zu wollen - verspuerte)

Wenn ich einen Drang verspüre, gehe ich still aufs Klo.

Andreas

ist dort die “community” ?

Hi,

Meinst du wirklich das die Tabelledefintionen tatsächlich sensible Infos enthalten? Auch wenn es so wäre , sowas läßt sich anonymisieren.

Abgesehen davon, habe ich dir schon erklärt, wie das Community-Modell bei PG funktioniert.
Wenn du nicht auf der ML postest, wird das anders gewerrtet.
Vielleicht bist du bei denen im SPam-Filter gelandet…
Was denkst du wieviel Post die täglich von wildfremden bekommen, die benutzen nämlich keine Wegwerf-Adressen.


Freundliche Grüße
hkocam

ob die nun enthalten sind oder nicht spielt doch garkeine rolle mehr …

ich habe nachgefragt - bei mind. 2 leuten - habe mich hingesetzt und den scheiss auseinandergetuetelt …

das problem ist ja auch (das habe ich denen auch erklaert) dass es datenabhaengig ist - das reduzierte modell liefert das symptom nicht.

es kommt einfach null reaktion … tut mir ja leid wenn ich nicht sofort alle informationen liefere die genehm waeren - ein dialog ist das jedenfalls nicht.

das funktioniert bei anderen projekten irgendwie besser.

ja- auch ich erhalte spam - und ich pruefe meinen spam - alle 2 - 3 tage …

Hi,

was meinst du mit reduziert ?
Hast du die Tabellendefinitionen geändert oder das Datenvolumen reduziert ?

Freundliche Grüße
hkocam

ich habe das modell auf 11 beteiligte tabellen reduziert. genau die tabellen, die in dem verwendeten view auftauchen, der in der query verwendet wird - und die tabellen die noch irgendwie mit dem view referenzieren (in der query).

ausserdem habe ich trigger und funktionen entfernen muessen (eh nur fuer inserts etc. notwendig - und die funktionieren auch nicht ohne den rest der DB).

zum nachvollziehen des modell sollte das reichen - die keys und foreignkeys sind alle dabei gewesen …

hat ziemlich arbeit gemacht, dasset passt - und man die query drauf ausfuehren kann … nur bloed, dass das problem im leeren modell nicht auftritt :slight_smile:

Hi,

wo ich die Anzahl Tabellen sehe, hast du mit diesen Parametern mal rumgespielt
PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Query Planning

oder hiermit PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Query Planning.

Freundliche Grüße
hkocam

guter hinweis … werd ich gelegentlich probieren … auch wenn ich es nicht fuer sehr wahrscheinlich halte, dass das wirkt - da hat sich ja gegenueber 8.3 nichts geaendert - was das verhalten angeht … gläube isch

ich habe für 8.4 einige meiner ansichten auf CTE umgestellt - was ja den größten teil der probleme mit den komplexen queries behoben hatte -> planner

heute ist mir beim tunen aufgefallen, dass bei einer konkreten query der planner plötzlich ganz andere ergebnisse liefert, wenn ein join mehr bzw. weniger drin auftaucht … auch wenn die table mit den “problem-tabellen” nichts direkt zu tun hatte. es war voellig egal welchen join ich weglies.

das lies natuerlich den schluss zu, nochmal die planner parameter anzuschauen - und tatsaechlich - dat hier hat geholfen

geqo_threshold = 32            # default 12

hmm … leider ist die doku bei qeqo nicht sonderlich gesprächig

nunja - ob das jetzt ein sog. “work-arround” ist - oder ob ich nicht sowieso irgendwann drueber gefallen waere, weiss ich nicht. etwas seltsam ist eben, dass in 8.3 die exakt gleiche situation mit exakt der gleichen query anders bewertet wird - das mag bei einem “grenzfall” wie meinem auch erklärbar sein.

join_… bwz from_collapse_limit habe ich auch mal etwas variiert - aber das half nicht sonderlich.

insgesamt tut jetzt aber alles so wie ichs moechte - leider kann ich aber die anwendung nicht mehr einfach so auf einer “standard-installation” von PG laufen lassen. das hatte schon was - einfach sagen zu koennen: “downloaden - installieren - freuen”.

soviel zu diesem thread - damit ihr informiert seid :slight_smile:

Hi,

danke für das Update.

freundliche Grüße
hkocam

fyi
Re: HashJoin w/option to unique-ify inner rel

wird beobachtet …

is aber fuer mich persoenlich nimmer akut …