Die Personalakte brauchte beim Oeffnen anderthalb Sekunden. Im Container
gemessen: person 4ms, hauptabfrage 1554ms, nachschlag 11ms. In der
Hauptabfrage steckt om_reporting_lines -- als postgres 60 ms, als
alpenwerk_app 1457 ms. Derselbe Aufschlag liegt auf allem: ein blosses
count(*) kostet unter RLS 44 bis 55 ms statt 7.
Ursache: ein Policy-Ausdruck wird je Zeile ausgewertet. `is_hr_user()` ist
zwar stable, aber das erlaubt Postgres nur, den Wert innerhalb einer
Anweisung als unveraenderlich anzusehen -- nicht, ihn aus dem Zeilenfilter
zu ziehen. Bei jeder Zeile laufen zwei Unterabfragen auf profiles und
app_passwoerter.
In einen Unterausdruck gefasst wird daraus ein InitPlan, einmal
ausgewertet. Ohne RLS gemessen, damit nur dieser Unterschied sichtbar ist:
om_positions where is_hr_user() 14,8 ms
om_positions where (select is_hr_user()) 0,5 ms
employees where is_hr_user() 4,1 ms
employees where (select is_hr_user()) 0,5 ms
Die Zugriffsentscheidung aendert sich nicht: dieselbe Funktion, dasselbe
Ergebnis, nur nicht mehr achthundertmal gefragt. Keine Tabelle verliert
ihre Policy, keine Rolle bekommt Rechte dazu, alpenwerk_app bleibt ohne
BYPASSRLS.
Der andere Weg -- om_reporting_lines auf security definer umstellen --
waere genau das nicht: er verschoebe die Grenze, um schneller zu werden,
und haelfe nur dieser einen Funktion.
Rund zwanzig Policies von Hand abzuschreiben hiesse, eine davon falsch zu
treffen und eine Tabelle zu oeffnen oder zu schliessen, ohne dass es
auffaellt. Deshalb werden die bestehenden Definitionen aus pg_policies
gelesen und unveraendert wieder angelegt; ersetzt wird allein der
Funktionsaufruf. Die Selbstpruefung zaehlt nach, dass keine offen blieb
und keine verlorenging.
