Hi Olaf,

>Another thing, that's irritating on the output of sys(3054) is, that you get "none" optimization messages for filter conditions on tables, that have no filter condition in the sql. This leads to the belief, that rushmore fails to fully optimize.
>for example: ...

Yes, such lines can put you on a false trail. OTOH, comparing the optimizations of different versions of the same query with "FORCE" added into the join is ***for me*** easier with those lines.

>How about ASHOWPLAN(ArrayName,nOption[,cSQL]), a new array function creating a showlplan array, that can be analized programmatically. Each line of the array would then show one step of the sql execution, one filter or one join:
...
Those different categories are beautiful - but the array appoach is more helpful if you are creating new stuff. Often I have to jump into existing code and just logging the SQL with sys(3092) helps to pinpoint some problems without bracketing all SQL-lines with calls to my measuring classes. So while I'ld clearly like to have more information, I'ld argue strongly for every information to be parseable from the logfile as well as the chance to access it from an array structure.

regards

thomas