SQL-Laufzeit durch Funktion erheblich länger?

[BenderD]

... an der function kann man sicher noch etwas optimieren; zuerst sollte man die Option DETERMINISTIC und RETURNS NULL on NULL INPUT angeben, ALLOW PARALLEL könnte auch noch was bringen - ob da in den Details noch was steckt, habe ich mir nicht angesehen...

D*B

[andreaspr@aon.at]

Die Option NOT FENCED könnte auch helfen, dadurch wird die Funktion nicht in einem seperatem Thread ausgeführt. Das wären dann 100.000 Threads die nicht erstellt und bereinigt werden müssten.

[Fuerchau]

Das wäre nur das Einsparen eines Threads, da nicht je Satz ein Thread gestarte wird!

[cbe]

danke für die Tips + Infos,
ich habe es mal ausprobiert mit
DETERMINISTIC, RETURNS NULL on NULL INPUT, ALLOW PARALLEL und NOT FENCED

Es ist tatsächlich ca. 1/4 schneller geworden - aber trotzdem noch deutlich langsamer als der einfache digits + concat.

Mein Kollege lässt es jetzt bei der Version ohne Funktion.

Gruß, Christian

[BenderD]

... kann man natürlich auch in eine View reinnageln, wg. dem Comfort.

Das grundsätzlich problematische an der Einbindung von Functions in Select Statements ist, dass der Optimizer nicht weiß, was die Function da zurück liefert, da fängt man sich leicht einen Fulltable scan ein.

D*B

[cbe]

... kann man natürlich auch in eine View reinnageln, wg. dem Comfort.

genau das hat der Kollege dann auch gemacht

Das grundsätzlich problematische an der Einbindung von Functions in Select Statements ist, dass der Optimizer nicht weiß, was die Function da zurück liefert, da fängt man sich leicht einen Fulltable scan ein.

ich muss gestehen, dass der Optimierer eh ein wenig Voodoo für mich ist. Die meisten Sachen, die ich brauche macht er ganz gut, manchmal muss ich ihn ein wenig in die richtige Richtung drängeln...
Aber das ist ein ausuferndes Thema, was ich hier gar nicht weiter vertiefen will - Jetzt ist Feierabend + Feiertag