Then I looked at sap's "expensive sql statements solution database" - no help there.
Then I tried looking for notes on the problem. Over 200 notes on "classification + performance", good luck with that.

Then I figured it out, index kssk~n1 had a low cluster ratio.
So I changed the clustering index , reorged the table and all was well, the i/o (getpages) cost went down to 3. ( I'd rather not say its original cost, it’s a bit embarrassing ).

You could say this problem is not really related to classification, that it could happen in many other cases, and that would be partly true.
But if you look at it the other way, the very low fullkeycard and the original cluster ratio of index kssk~n1 are not coincidences, they are a direct result of the classification code and data model (erd ), and one day I hope to understand enough about them to prove my last claim ( or disprove it …)

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.