Hallo Zusammen,

ich habe heute entdeckt, dass man im Firebird 3.0 Stored Functions das Schlüsselwort "Deterministic" mitgeben kann.

Beispiel:

markieren

Delphi-Quellcode:

create or alter function SF_CRLF
returns char(2) deterministic
AS
begin
  return ascii_char(13) || ascii_char(10);
end

Ich frage mich nur, was das bedeutet?
Leider bringt mich die Googlesuche nicht sonderlich weit und die ReleaseNotes auch nicht.
Ich finde nur Hinweise darauf, dass man nun per isql auswerten kann, ob es sich um eine deterministic-Funktion handelt, oder nicht.
Und ich habe ein Ticket gefunden, in dem beschrieben wird, dass das nur bei Funktionen Sinn ergibt, die

Ich habe nun die Vorstellung, dass er Prozeduren, die immer den gleichen Rückgabewert haben anders kompiliert und die BLR vorteilhafter ist.
Das ist aber nur so eine Vermutung. Hat da jemand gesicherte Informationen?

Gruß Jan

Laut : https://ib-aid.com/en/articles/45-wa...bird-database/

Zitat:

39. Mark appropriate PSQL functions as DETERMINISTIC
Mark your PSQL functions (in Firebird 3+) which do not have parameters and return constant values with keyword DETERMINISTIC. The deterministic functions are calculated and cached in the scope of the current query.

getestet habe ich das nicht, ist aber je nach bedarf bestimmt interessant....

Einige DBMS bieten es an, dass man SPs entsprechend markieren kann, wenn sie bestimmte Bedingungen erfüllen, wie Beispielsweise
* Result ist immer NULL, wenn mindestens ein Parameter NULL ist -> ist ein Parameter NULL, braucht die SP also garnicht erst ausgeführt werden
* SP verändert keine Daten in der DB (macht nur SELECTs, aber kein INSERT/UPDATE/DELETE)
* SP gibt immer das selbe Ergebnis zurück, bei gleichen Parametern (während dieser Abfrage, innerhalb der Connection/Session oder gar für die ganze Laufzeit der DB)
* ...

So kann das DBMS seine Arbeit besser steuern, indem es z.B. Ergebnisse cached und die SP seltener ausführt.

Du hast z.B. eine Funktion im SELECT/WHERE, die für zu einem Wert immer den gleichen anderen zugehörigen Wert holt.
SELECT id, xyz, GetValueFromXyz(xyz) FROM table WHERE ...
Hast'e jetzt deine SP als DETERMINISTIC markiert, dann kann FB den aufruf optimieren, für den Fall die Funktion wird mehrmals mit dem selben Parametern aufgerufen.

Normal bräuchte dieses SELECT 20 Sekunden und deterministisch nur 5.

zusammenfalten · markieren

SQL-Code:

CREATE FUNCTION TestDeterm(param1 INTEGER) RETURNS INTEGER DETERMINISTIC AS
  BEGIN
    Sleep(1000); -- k.A. wie man das in FB macht
    RETURN param1 * 2;
  END;

SELECT TestDeterm(x)
FROM (VALUES
  (1), (2), (3), (4), (5),
  (1), (2), (3), (4), (5),
  (1), (2), (3), (4), (5),
  (1), (2), (3), (4), (5)
) AS temp (x)

anderes Beispiel:
IMMUTABLE | STABLE | VOLATILE | [ NOT ] LEAKPROOF
https://www.postgresql.org/docs/curr...efunction.html

Zitat:

Sleep(1000); -- k.A. wie man das in FB macht

Sleep in einer SP

Neben den Erläuterungen von Himitsu würde ich ergänzen (halbwissen), dass der Determinismus sinnvollerweise an die Eingangsparameter gekoppelt sein muss.

Wenn also wie in einem Beispiel, nur ein Zeilenumbruch geliefert wird, ganz ohne Parameter find ich das schon ziemlich(? gibt es das?) deterministisch.
Wenn der Zeilenumbruch abhängig von einem Eingangsparameter Windows:boolean true|false geliefert wird, immer noch ziemlich deterministisch, denn konstante Eingangsparameter liefern immer gleiches Ergebnis.
Liefert die Funktion aber einen Zeilenumbruch im Windows oder Unixstyle abhängig von sagen wir den Usersettings und dessen bevorzugter CSV Ausgabeeinstellung, wird es schwierig mit deterministisch.
Bei einer DB dürfte m.E. hier auch der DB Kontext eine Rolle spielen, also Session oder auch nur Transaktion. Da könnte sogar eine Funktion getCountOfTable deterministisch sein, wenn sie innerhalb der Transaktion nicht geändert wird.

Am Ende alles implementierungsabhängig. Wenn die Doku nichts hergibt, hilft nur ausprobieren. Am besten gleich mit einer Count(*) Funktion auf einer großen Tabelle, sprich einer Funktion, die auch viel Zeit braucht und damit leicht messbar ist und gut prüfbar, was den Rückgabewert angeht.

Zitat von mkinzler:

Sleep in einer SP

Andere können das doch auch?
PERFORM pg_sleep(1000); -- SELECT pg_sleep(1000);
Und für ein billiges schnelles Testen/Debugging kann man es schonmal gebrauchen. (Laufzeit- und Timeout-Tests)

Alles mit Jedem verlinken verbrät auch ein klein bissl Zeit.

markieren

SQL-Code:

SELECT * FROM GrosseTabelleA, GrosseTabelleB, GrosseTabelleC
-- bzw.
SELECT *
FROM GrosseTabelleA
JOIN GrosseTabelleB ON true
JOIN GrosseTabelleC ON true

ORDER BY 1
LIMIT 1

Noch ein Hinweis dazu, falsche DB aber einigermaßen erklärt.
https://msdn.microsoft.com/de-de/library/ms178091.aspx