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

Ist das inzwischen, wie auch immer, auf der Hackers-ML gelandet?

Andreas

Hi,

ich habe nichts unternommen, habe aber auch nichts mit dem Thema bis jetzt auftauchen sehen.
@symbiont Es wäre wirklich wichtig, das Projekt an dieser Stelle zu unterstützen. Wäre unschön, wenn dieses Problem ungesehen in das Release geht. Mein Angebot steht immer noch, brauche aber deinen Input.

Freundliche Grüße
hkocam

Full ACK.

Zur Info, was bei sowas passieren kann:

Stefan Kaltenbrunner hat am Sonnabend einen Bug reportet, 2 Stunden später hat Tom Lane das bestätigt und 6 Stunden später war der Patch fertig. Die Beta 2 wird wohl bald kommen, symbiont sollte nun mal ausschlafen…

Andreas

An sich könnte/sollte symbiont das selbst einreichen: sonst müssen Rückfragen auch über eine dritte Stelle gehen und das macht die Kommunikation ineffektiv und ev. fehlerhaft.

Hi,

Hast völlig recht, aber bevor es völlig untergeht…

Allerdings ist die Hürde für dieses spezielle Unterfangen recht hoch:

  1. Kommunkation auf Englisch
  2. Eventuell sensible Kundendaten betroffen
  3. ORM liefert völlig unleserliche Queries

Eine Verenfachung auf einen nachvollziehbaren Testcase ist da quasi Notwendigkeit und das dauert leider bzw. ist schwierig zu erledigen.

Trotzdem wäre es echt toll wenn symbiont das hinkriegen würde.

Freundliche Grüße
hkocam

oder morgen …

ich hatte ne menge zu tun - kam nicht dazu …

Vereinfachung ist nicht drin weil

  • woher soll ich wissen, warum das problem genau auftritt?
  • oder ob bei einer vereinfachung der planner zum richtigen ergebnis führt?

ich werde das problem mal so schildern wie es auftritt - wenn ich da feedback erhalte, werde ich mal weitersehen - vielleicht mach ich mir die muehe teile des betroffenen modells etwas aufzubereiten … im grunde sind nur zwei tabellen beteiligt … wie ich das mit den daten mache weiss ich noch nicht.

mein englisch is nich perfekt - dafuer reichts aber allemal …

Hi,

Am Besten nimmst du Teile weg und vergleichst die Pläne und Laufzeiten für das Query.

Die Daten in deinen Tabellen interessieren erst einmal nicht, aber die Tabelledefinitionen(inkl. PK/FK/Indize/Trigger).

Freundliche Grüße
hkocam

das ist zeit die ich gerade nicht habe … (mail ist uebrigends raus)

außerdem denke ich, dass anhand der zwei pläne das problem sehr deutlich wird. ich habe den alten mitgeschickt und auch die query. da sieht man, dass indizes der foreign-key constraints verwendet werden. in dem neuen (8.4) sieht man stattdessen die semi-joins und so kram.

vielleicht reichts ja … ich meine wenn ich meinen code so im kopf habe reichen oft auch schon seltsame berichte mit wenig informationen um auf probleme zu kommen. vielleicht ists ja was offensichtliches … wenn nicht werd ich mich weiter bemuehen.

ich meine der planner entscheidet hier zwischen zwei konkurrierenden verfahren einfach etwas zu falsch - ohne den PG code zu kennen denke ich, dass er hier einfach zu entusiastisch bei einem EXISTS das nach “der neuen Methode” zu loesen versucht, ohne zu beruecksichtigen, dass man frueher ja auch EXISTS erfolgreich eingesetzt hatte und dafuer indizes quälte. naja … alles spekulation - wir werden sehen.

wie zu erwarten kam die frage nach dem modell …

ich kann das nich einfach so verschicken … und aufbereiten macht ziemliche muehe …

wenn ich mich da jetzt durchquaele - hoffe ich ihr liebt mich dafuer :slight_smile:

wir beobachten steven king.

Andreas

yeah … so ein scheiss … jetzt hab ich das modell mal reduziert … und in der leeren db sieht der plan auch in 8.4 wieder “vernuenftig” aus … index-scans wohin das auge reicht …

ich kann die daten-bank nicht schicken … der inhalt ist vertraulich

Nun, du erwartest eine Lösung für dein Problem. Und von alleine passiert da nichts.

hi,

dann schick das Modell trotzdem mit dem Hinweis, das die Probleme datenabhängig sind.
Was du noch machen kannst, ohne zuviel sensible Werte mitzulifern, ist die passenden Einträge aus der pg_stats-view (PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: pg_stats) mitzuliefern.
Diese View benutzt der Planer zur Entscheidungsfindeung.

Freundliche Grüße
hkocam

symbiont: übrigends, wenn du dein Posting nachträglich änderst, bekommt das niemand mit. Dafür wird keine neue Benachrichtigungsmail generiert.

och - naja … problem … wär ich boese, dann koennt ich das auch ignorieren :slight_smile:

so akut ist es ja nicht.

Und wäre ich böse würde ich dich darauf hinweisen, dass du wolltest, das deine Anwendung auf 8.4 läuft.

Andernfalls bleib halt bei 8.3 und verlagere das Problem mehrere Jahre in die Zukunft :wink:

guter hinweis - denke ich … vielleicht schick ich die gleichen stats aus 8.3 gleich mit - wenn sie sich unterscheiden - mal schauen ob ich da was erkenne

Nochwas

Die Spalte most_common_vals der pg_sats-view enthält echte Werte, alles andere ist nur Statistik-Material.
Edit:
Die Spalten most_common_vals und histogram_bounds der pg_sats-view enthalten echte Werte, alles andere ist nur Statistik-Material.

g … ich war halt neugierig - weil von 8.2 nach 8.3 wars ja nicht ohne weiteres moeglich. 8.4 is halt beta - keine ahnung wie wahrscheinliche es ist, dass jemand anderes ueber das gleiche problem stolpert

und außerdem betrifft das problem ein feature, dass ich in 8.4 dank CTE eigentlich nicht mehr habe :slight_smile:

aber wir wissen - frueher oder spaeter holt es uns ein