Memoize in Postgres Ausführungsplänen

Im Artikel Waiting for PostgreSQL 19 – Display Memoize planner estimates erklärt Hubert Lubaczewski, was es mit dem Schlüsselwort Memoize in Postgres Ausführungsplänen auf sich hat: es handelt sich um einen seit Version 14 verfügbaren Caching-Mechanismus, der wiederholt benötigte Informationen in einem Cache-Bereich einer bestimmten Größe ablegt und im "actual plan" Informationen über die Trefferquote in diesem Cache gibt. Mit Version 19 wird diese Information dann bereits im simplen explain (ohne analyze) - also vor der Ausführung abgebildet.

Konzeptionelle Unterschiede zwischen Postgres und Oracle

Gerade stellte ich mir die Frage, wie ich diese Links später noch mal finden könnte, und dann fiel mir ein, dass ich dafür einst eine gute Lösung hatte: meinen Blog. Daher bringe ich den Verweis auf die folgende interessante Artikelserie von Kellyn Pot’Vin-Gorman, die Oracle und Postgres aus konzeptioneller Sicht gegenüberstellt:

• Oracle DBA to PostgreSQL, Part 1: Install and Architecture
  
• PostgreSQL for the Oracle DBA, Part 2: Physical Data Structures, Storage, and Processes
  
• PostgreSQL for the Oracle DBA, Part 3: Transaction Control, Locking, and Performance Insight
  
• PostgreSQL for the Oracle DBA, Part 4: Query Tuning and the PostgreSQL Planner
• PostgreSQL for the Oracle DBA, Part 5: Understanding Wait Analysis
  
• PostgreSQL for the Oracle DBA, Part 6: Tuples, MVCC, and Two Views
  

Ich denke, die Übersicht ist als idealtypischer Vergleich von beiden Seiten her nützlich: für den Postgres- wie für den Oracle-Nutzer. Vermutlich werden hier noch weitere Artikel folgen, aber ich habe keine Ahnung, ob ich die Liste ergänzen werde.

if (not) exists für DDL in Oracle 23c

Noch ein nützliches Detail, das es in Oracle 23c geschafft hat - und das bei anderen RDBMS schon länger im Spiel war: die Möglichkeit, Fehler in SQL Skripten zu vermeiden, die sich aus der Existenz oder Nicht-Existenz von Objekten ergeben:

• create ... if not exists
• drop ... if exists

Bisher benötigte man in solchen Fällen eine relativ aufwändige Prüfung, die man sich nun sparen kann. Natürlich birgt das auch ein gewisses Risiko, da man damit natürlich wunderbar produktive Objekte beseitigen kann, aber bei DDL sollte man ohnehin immer vorsichtig sein. Eine detaillierte Erläuterung liefert - natürlich - Tim Hall: https://oracle-base.com/articles/23c/if-not-exists-ddl-clause-23c.

Group By Erweiterung in Oracle 23c

Nein, ich schreibe hier nichts mehr, aber eben habe ich eine interne SQL Schulung gehalten und darin behauptet, dass Oracle eine Positionsangabe im group by nicht unterstützt:

cdb$root@SYS:some-system > select username, count(*) from v$session group by 1;
select username, count(*) from v$session group by 1
       *
FEHLER in Zeile 1:
ORA-00979: Kein GROUP BY-Ausdruck

Mit Oracle 23c ändert sich das offenbar, wie Dani Schnider in https://danischnider.wordpress.com/2023/04/07/group-by-extensions-in-oracle-23c/ erläutert. Natürlich spendiert Oracle dafür auch noch einen Parameter group_by_position_enabled, den man auf true setzen muss, wenn man das Feature auch noch nutzen möchte.

Postgres Links: selten genutzte Features und Tipps zur Massendatenbehandlung

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

Der Artikel "Lesser Known PostgreSQL Features" von 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.

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.

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.

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.