Freitag, Mai 27, 2022

Postgres Links: selten genutzte Features und Tipps zur Massendatenbehandlung

Nur, damit ich die Artikel - vielleicht - wieder finde: 

Der Artikel "Lesser Known PostgreSQL Features" Haki Benita stellt - nun ja: ein paar weniger bekannter Postgres Features vor... An mir vorbei gegangen war unter anderem gen_random_uuid, womit man seit Version 13 uuid-s erzeugen kann, ohne die uuid.ossp extension installieren zu müssen.

Auf interessant ist "Common DB schema change mistakes" von Nikolay Samokhvalov, der erläutert, was man bei Massendatenoperationen besser vermeiden sollte. Hier finde ich den Hinweis auf "drop index concurrently" interessant: das hatte ich nicht mehr in Erinnerung.

Freitag, Februar 25, 2022

Oracle Transformationen

 Jonathan Lewis hat bei Redgate eine Serie zu Transformationen des Oracle Optimizers gestartet:

  • Transformations by the Oracle Optimizer: erläutert das unnesting von IN-Listen, die zu inline Views umgewandelt werden, die dann in einen Join einbezogen werden können. Außerdem werden die query blocks angesprochen, die in den Ausführungsplänen erscheinen und zur Hint-Definition eingesetzt werden können.
  • The effects of NULL with NOT IN on Oracle transformations: erklärt (noch mal), warum es nicht immer möglich ist, NOT IN zu NOT EXISTS umzuwandeln, und inwieweit NOT NULL Constraints das ändern können. Zur Analyse des Verhaltens können die Suffixe "NA" (null-aware/accepting) und "SNA" (single null-aware/accepting) bei den Joins im Ausführungsplan herangezogen werden.

Früher habe ich an dieser Stelle gerne behauptet, dass ich folgende Artikel später ergänzen würde - aber da das schon optimistisch war, als ich noch mehr Zeit hatte, spare ich mir diese Absichtserklärung jetzt.

Donnerstag, Dezember 30, 2021

Rekursive CTEs

 Ja, mir ist schon klar, dass 2021 nicht das beste Jahr für diesen Blog war - wofür der Grund der übliche war: jede Menge Arbeit. Und, ich nehme es vorweg, 2022 wird nicht viel besser. Aber völlig einschlafen soll er auch nicht, so dass ich vor dem Jahresende schnell noch Franck Pachot mit seinem Artikel "Learn how to write SQL recursive CTE in 5 steps" erwähne, in dem er hübsch kompakt erklärt, wie man sich eine rekursive CTE aufbaut und wozu die Einzelteile gut sind. Auch als Apostel des yubabytedb Kults bleibt der Herr Pachot extrem lesenswert.

Donnerstag, November 26, 2020

Oracle Performance-Gründe gegen "select *"

Nichts Neues ist, dass der Zugriff auf Tabellen ohne eine explizite Angabe der relevanten Spalten - also mit: select * from table - aus sehr vielen Gründen in der Regel keine gute Idee ist. Tanel Poder hat jetzt eine schöne Liste mit Punkten erstellt, die im Oracle-Kontext die Performance-Aspekte des Themas betreffen. Einige dieser Punkte sind auch für andere RDBMS in gleicher oder ähnlicher Weise relevant.

Freitag, Oktober 23, 2020

Postgres Performance seit Version 8.3

Ja, es ist eine Weile her, seit ich hier zuletzt etwas geschrieben habe. Und so richtig viel Neues kommt auch jetzt nicht. Nur der Link auf eine interessante Untersuchung von Tomas Vondra von 2ndQuadrant, der die Performance von Postgres beim TPC-H Benchmark für die Versionen 8.3 bis 13 untersucht. Die Ergebnisse sind in vielen Details sehr interessant und zeigen unter anderem die Rolle, die die Parallelisierung bei den neueren Releases spielt. Aus den Graphen würde ich ableiten, dass die letzten Releases seit Version 10 keine extrem spektakulären Performance-Verbesserungen mehr gebracht haben, aber durchaus eine positive Entwicklung. Das mag aber auch an der Skalierung liegen, da die Verbesserungen davor sehr deutlich sichtbar waren.

Donnerstag, Juli 09, 2020

Join-Performance in relationalen Datenbanken

Damit ich den Artikel in Zukunft wiederfinde, um darauf verweisen zu können: Franck Pachot beschäftigt sich in seinem jüngsten Artikel mit dem Mythos der langsamen Joins in relationalen Datenbanken. Die dahinter stehende Vorstellung, die in den Kreisen der reinen NoSQL Enthusiasten häufig geäußert wird, ist, dass Join-Operationen in relationalen Datenbanken langsam sein müssen, da hier große Datenmengen verknüpft werden müssen, was zu einer hohen Komplexität, CPU-Last etc. führen muss, die sich abhängig von der Größe der Tabellen erhöhen.

Franck Pachot erklärt, dass diese Annahme übersieht, dass alle relationalen Datenbanken über B*Tree Indizes verfügen und die den key-values Stores vergleichbaren kleineren Suchoperationen in aller Regel mit Nested Loop Joins abbilden, wodurch die Größe der Objekte keine Rolle spielt. Er zeigt auch - am Beispiel von Postgres -, dass der Optimizer des RDBMS hier nicht als Black Box agiert (auch das ein üblicher Einwand gegen die relationalen Datenbanken), sondern Pläne über Explain Kommandos darstellen kann.

Sehr schön am Artikel ist auch, dass er sehr sachlich bleibt - und Alex DeBrie, der Autor des Artikels aus der NoSQL-Gemeinde, auf den Franck Pachot sich bezieht (und in dem sich der Abschnitt "Why relational databases don't scale" findet) in Twitter den schönen Satz "really great post by Franck Pachot, and I'm grateful for the conversation" schreiben kann. Wobei ich insgesamt den Eindruck habe, dass heute solche technischen Auseinandersetzungen in vielen Fällen etwas zivilisierter ausgetragen werden, als das in früheren Zeiten (sagen wir: vor 10, 15 Jahren) der Fall war.

Freitag, Mai 15, 2020

Plan Prädikate in AWR mit Oracle 20

Nur damit der Blog nicht völlig einschläft: Franck Pachot weist in seinem Blog darauf hin, dass Oracle 20 nun endlich die "predicate information" in AWR abspeichert, wie das seit Generationen gewünscht worden war - insbesondere vom Herrn Pachot, der dazu im Jahr des Herrn 2014 eine Idee im Oracle Developer Forum untergebracht hatte; wie ich sehe, sind die von mir dort vorgeschlagenen Verbesserungen alle noch nicht umgesetzt... Leider komme ich heute kaum noch ins Forum und schon gar nicht, um dort etwas zu schreiben. Oder auch: Tempora mutantur et nos mutamur in illis.

Montag, April 06, 2020

dense_rank zur Bestimmung von Maximalwerten pro Gruppe

Wie man nicht nur am Alter des letzten Eintrags, sondern auch am Titel des vorliegenden erkennen kann, komme ich derzeit selten dazu, mir Gedanken über technische Fragen und ihre schriftliche Zusammenfassung zu machen: und da werden die Titel dann offenbar sperriger...

Jonathan Lewis behandelt in seinem Blog eine Einsatzmöglichkeit der analytischen dense_rank Funktion, der mir gelegentlich auch schon geholfen hätte. Die Fragestellung ist dabei die der jüngsten Bestellung, die in einer Transaktionstabelle für jeden einzelnen Kunden vorliegt. Dazu werden diverse Varianten mit korrelierten und nicht korrelierten Subqueries überprüft, die jeweils das Problem mit sich bringen, dass die Transaktionstabelle zweimal gelesen werden muss. Vermeidbar ist das mit analytischen Funktionen, wobei zunächst eine inline-View mit einem analytischen MAX verwendet wird, bei dem dann in der rahmenden Query eine Filterung auf diese maximalen Werte erfolgt - und das wäre wahrscheinlich auch die Lösung gewesen, die mir in diesem Fall eingefallen wäre. Noch effizienter ist hier aber ein "max (...) keep (dense_rank last order by ...)". Voraussetzung ist dabei, dass es möglich ist, einen unique constraint über die Gruppierungsspalte und die order by Spalte zu legen, da es sonst zu falschen Ergebnissen kommen kann. Grundsätzlich kann die Strategie aber sehr nützlich sein, wenn die Zahl der Datensätze in der Transaktionstabelle im Verhältnis zur Anzahl der (distinkten) Werte in der gruppierten Ergebnismenge der Query hoch ist.

Wenn ich das noch mal überfliege, wird mir klar, dass nicht nur die Titel unter der selteneren Übung beim Zusammenfassen leiden...