Codeoptiierung

Fragen und Probleme rund um die Abfragespache SQL.
mwapost
Neuer Benutzer
Beiträge: 7
Registriert: Sa 5. Okt 2019, 20:55

Re: Codeoptiierung

Beitrag von mwapost » So 13. Okt 2019, 19:07

Hi,

mir ist im übrigen noch etwas aufgefallen:
Ich dachte mir ich könnte der Spalte Zeit auch einen Constraint mitgeben, dass diese Spalte eindeutig sei. Meine Erwartung war, dass dann alles schneller wird. Allerdings war das nicht so. Mein Code von vorher 6.8 Sekunde verdoppelte sich auf 13,6 Sekunden. Dafür verkürzte sich der Code von pogomips von 13,6s auf 12,0 Sekunden.

Wie kann man Postgres beibringen, in einer geordneten Tabelle zu suchen. Dass sollte ja innerhalb eines Betweens die Geschwindigkeit enorm verbessern, oder? Ich dachte da an sowas wie ein Constraint und eine Art Index, welcher von einer sortierten Tabelle ausgeht?

pogomips
Erfahrener Benutzer
Beiträge: 114
Registriert: Fr 18. Nov 2016, 09:55

Re: Codeoptiierung

Beitrag von pogomips » So 13. Okt 2019, 20:12

Schade, das hatte ich mir irgendwie anders vorstellt.

zu den beiden Codevarianten:
Ich habe Dich so verstanden, dass die WITH Variante von Dir innerhalb einer Funktion eingesetzt wird/ werden soll.
Meine Variante soll das jedenfalls nicht. Ich gehe davon aus, die Zeitangaben stammen von den Laufzeiten genau dieser Statements.

Dann sieht man, dass die Laufzeiten mit meinem Statement sich grob verdoppeln.
Die With Clause Variante schafft tatsächlich eine Single Pass Lauf, meine Variante durch das Count(*) braucht 2 scans, doppelt so lange. Also eigentlich alles erwartbar.

Wenn Du bei einem Single Pass "angekommen" bist, muss das Tuning schon sehr filigran werden. Viel Aufwand, wenig Verbesserungspotential.
Das läuft dann vielleicht eher darauf hinaus, ein "Anwendungstuning" zu machen oder die Postgres Parameter an die Raspi Umgebung / Aufgabenstellung zu optimieren.

Zu Deinem letzten Post, Sortierung will man nicht, wenn vermeidbar, sie kostet extra Ressourcen, die gerade auf dem RASPI knapp sind.

mwapost
Neuer Benutzer
Beiträge: 7
Registriert: Sa 5. Okt 2019, 20:55

Re: Codeoptiierung

Beitrag von mwapost » So 13. Okt 2019, 20:17

Mhh zum Thema Sortierung,

ich denke die größte Ressource welche die Abfrage frisst sitzt in dem Group by in Verbindung mit der Where Klausel. Bevor gruppiert wird muss jedesmal die ganze Tabelle nach allen Möglichkeiten durchsucht werden. Das ist natürlich aufwendig. Wenn man aber bedenkt, dass bei einer sortierten Tabelle die werte direkt hintereinander stehen, dann sollte das Gruppieren doch sehr schnell von der Hand gehen, oder? Aber vielleicht macht das ja Postgres bereits im Hintergrund.

castorp
Erfahrener Benutzer
Beiträge: 1177
Registriert: Sa 27. Jun 2009, 22:24
Wohnort: Bayern

Re: Codeoptiierung

Beitrag von castorp » So 13. Okt 2019, 21:56

mwapost hat geschrieben:
So 13. Okt 2019, 20:17
ich denke die größte Ressource welche die Abfrage frisst sitzt in dem Group by in Verbindung mit der Where Klausel
Das kannst Du ganz leicht mit explain (analyze, buffers)... überprüfen
Wenn man aber bedenkt, dass bei einer sortierten Tabelle die werte direkt hintereinander stehen
Tabellen in einer relationalen Datenbank sind nicht sortiert - Du kannst Dir das vorstellen wie eine Korb mit Bällen.
A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

pogomips
Erfahrener Benutzer
Beiträge: 114
Registriert: Fr 18. Nov 2016, 09:55

Re: Codeoptiierung

Beitrag von pogomips » Di 15. Okt 2019, 21:02

mwapost hat geschrieben:
So 13. Okt 2019, 20:17
ich denke die größte Ressource welche die Abfrage frisst sitzt in dem Group by in Verbindung mit der Where Klausel. Bevor gruppiert wird muss jedesmal die ganze Tabelle nach allen Möglichkeiten durchsucht werden. Das ist natürlich aufwendig. Wenn man aber bedenkt, ..
Jein. Du hast einerseits Recht, ein Aggregat über 1.5 Mio Zeilen ist kein Pappenstiel. Aber es gibt andererseits Einschränkungen. Damit ist es dann, bei nutzbarem Index kein Fullscan. Ein kleiner Zeitraum müsste entsprechend schnell durch sein.

Das mit der Sortierung hat castorp ja beantwortet, Sortierung gibt es nicht geschenkt. Und wie gesagt, gerade ein Raspi mit wenig RAM/SD macht da schnell die Grätsche.

Beim Thema Sensordatenauswertung auf Klein(st)systemen hat man ja eigentlich die Kanone und den Spatz. Das scheint bei 1.5 Mio Datensätzen nicht unbedingt einleuchtend, aber eine vollwertige DB ist an der Stelle vielleicht eben doch ein Overkill. Sie bietet eine Menge Funktionen, die man bei der Messwerterfassung und oder Reporting nicht braucht.

Hilfreich ist hier vielleicht eine Erfassung von bereits gemittelten Daten - zur deutlichen Reduktion der Datenmenge- anhand einer begrenzten Standardabweichung. Das erledigt man beim Datensammeln. Ergebnis sind dann schwankende Intervallzeiten und dennoch hohe Genauigkeit bei Messwertschwankungen.

Antworten