ich versuche gerade ein minimal Beispiel zu bauen, es sieht aber nicht genau so aus wie bei meinem Problem. Zu dem Problem:
Ich möchte eine Tabelle mit Daten joinen mit einer anderen Tabelle, die das Grouping vorgibt.
Dann sollen die Daten aggregiert werden (bisher über Group By).
Tabelle groupst mit grid und id2 bestimmt das Grouping (Primary Key/index: (id2, grid)).
Tabelle ids enthält die Daten (id2) zu speziellen id1. Auch hier primary key: (id2, id1).
Nun werden diese Daten über einen Nested Loop gejoint (bei mir nutzt er für beide Tabellen einen Index Scan).
Das Group By geht über id1 und grid, also über beide Tabellen hinweg.
Um das gescheit gruppieren zu können, müssen die Daten dementsprechend sortiert sein.
Das ist die der Teil der Ausgabe (Analyse), der sich um das sortieren kümmert:
Sort Key: ids.id1, groupst.grid
Presorted Key: ids.id1
Frage:
Warum erkennt das System nicht, dass der Zugriff über den Index der Tabelle (groupst mit index groupst_pkey), schon nach grid sortiert ist, also auch nach groupst.grid?
2.Frage:
Habt ihr einen besseren Ansatz für solche Anforderungen?
Vielen Dank für eure Hilfe!
Beste Grüße, Ludwig Rahlff
Ok, besten Dank, dann werde ich mal schauen, dass ich mir auch einen PostgreSQL16 Dienst aufsetze.
– Edit
Ja, mit Postgresql 16 scheint er auch bei mir ein HashAggregate zu nutzen.
Hintergrund:
Ich möchte Daten aggregieren, um weitere Werte zu berechnen. Die Daten liegen in einer Hierarchischen Struktur vor (in der folgenden Anfrage vernachlässigt). Dabei soll es Beispielsweise um Messpunkte (bspw. Spannung, Streckung) gehen, die jeweils zu einer Messreihe gehören. Nun möchte ich auf Messreihen-Ebene mit diesen Daten rechnen. Damit die Zuordnung der jeweiligen Parameter zueinander nicht verloren geht, habe ich diese in einem json aggregiert (1. Teil im 3. Anfrageblock).
Die Messreihen gehören zu einer Probe, an der mehrere Messungen durchgeführt wurden.
Nun möchte ich etwas berechnen aus den verschiedenen Messreihen, aber immer mit der gleichen Dehnung. Dafür gibt es die Tabelle complex_groupcond, in der beschrieben wird nach welchen Parametern gruppiert werden soll (dies können auch mehrere sein, was zu dem folgenden Problem führt).
Meine Anfrage ist doch etwas komplexer:
Auch hier scheint er das (äußere) Group by mit einem Hash-Algorithmus zu lösen.
Ich möchte alle Werte aus values in der inneren Anfrage nur einmal haben (daher der distinct), aber aus dem value (json) Werte für das Group by in der äußeren Anfrage konkateniert bereitstellen. Da er den Kram joint (mit keinem Unique key), können die Werte aus values “verdoppelt” werden. Daher brauch in den Distinct, für den quasi auch (wie für die window function) sortiert werden muss.
Frage: Warum muss er überhaupt sortieren? Da er den Index complex_in_pkey nutzt weiß kommt die gejointe Tabelle ja schon sortiert dazu?
Frage: Ist mein Ansatz der Falsche zur Lösung des Problems? Wäre es besser mit einem unique constraint zu joinen, sodass die Zeilen nicht verdoppelt werden?
Dann bräuchte ich eine Funktion die den json nimmt und ein aggregat aus complex_groupcond, und damit die group condition bildet. Meinen Sie/Meint ihr das wäre ein besserer Ansatz?
Frage: Oder wäre es sinnvoller alle Parameter blank weiterzugeben, und die hierarchie zu tracken und anhand dieser für die Berechnung zu sortieren?