Der Aufwand bei einem 'naiven' Subselect wird O(n^2) bleiben, denn für jede Zeile wird die Summe ausgerechnet. Bei einem einmaligen 'manuellen' Rechnen dagegen ist der Aufwand O(n). Ich kann mir jetzt nicht vorstellen, das ein Optimizer begreift, das man in einem Subselect ein 'running total' ausrechnet und das auch in O(1) ginge (Ergebnis der letzten Zeile + Wert). Aber Optimizer vollbringen wirklich wahre Wunder, vielleicht auch hier.
Tipp zur gefilterten Anzeige :
SQL-Code:
select * from (
SELECT *,
SUM(wert) OVER(ORDER BY lfd
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
AS Summe
FROM Table1
) x where lfd>3
Diese
Query erzeugt zuerst die laufende Summe über alle Zeilen und zeigt dann nur die Zeilen mit 'lfd' > 3 an. Schnell genug sollte das auch sein.
Die laufende Summe (bzw. die Pflege) könnte man auch über einen Trigger lösen, aber derart redundante Information hat normalerweise nichts in einer Produktivdatenbank (3NF) verloren.