Zwischen Select und Endselect wird nicht alles selektiert

Frank Münker hat geschrieben:aber was ich nicht verstehe ist, warum eine SELECT * Anweisung performanter sein soll als eine SELECT feld1 feld4 feld7 - Anweisung ?

Wenn wegen des *, das immer und überall verwendet wird, kein neues PREPARE mehr nötig ist, weil das schon gepufferte Statement vom Applikationsserver wiederverwendet werden kann, und das Fetch und der Netz-Transfer im Vergleich zum eingesparten PREPARE nicht zu langsam sind.

Frank Münker hat geschrieben: Hmmm .... interessanter Aspekt. Allerdings ist im gegebenen Fall ja die WHERE - Bedingung in jedem Schleifendurchlauf anders, dann müsste also trotzdem immer ein neues PREPARE notwendig werden, oder ?
Wenn sie aber immer gleich wäre, dann würde nur beim ersten Mal von 10.000 Durchläufen ein neues PREPARE fällig.

Also, ich denke, wenn ich einen einzigen SELECT SINGLE auf eine kleine (sprich: "schmale" )Tabelle mache, dann kommt es wohl aufs gleiche raus, aber bei vielen Datensätzen von "breiten" - Tabellen ist das FETCH und der Netz-Transfer bei einem SELECT * bestimmt sehr viel langsamer.

Es geht ja irgendwo auch um die Performance des Gesamtsystems, nicht nur der einzelnen Anwendung.

Hast Du schon mal im SQL-Trace nachgesehen, was das PREPARE zu einem SELECT SINGLE kostet im Vergleich zum FETCH?

Ein neues PREPARE ist nicht nötig, wenn sich nur die Inhalte in der WHERE-Klausel ändern (also z.B. gleiche Anzahl von Einträgen in Select-Option, gleiche Reihenfolge bei SIGN/OPTION).
Um ein Prepare wiederverwenden zu können, muss auch die Reihenfolge der zu selektierenden Felder übereinstimmen
Es wird nur eine begrenzte Anzahl von aufbereiteten Statements gepuffert, danach werden die ältesten nicht mehr benötigten Statements entsorgt, und es ist bei Wiederholung ein neues PREPARE nötig

Hast Du schon mal ausgerechnet, wie viele verschiedene SELECT SINGLE felfx feldy feldz... man auf die VBRK machen kann?

In o.g. Beispiel ist aber unstrittig, dass SELECT SINGLE * suboptimal ist.