@optimize for n rows:
hat (im Unterschied zu fetch n rows only) mit der Anzahl der tatsächlich zu liefernden Sätzen nix zu tun.
Den Effekt kann man oft beobachten, wenn man interaktives SQL per STRSQL, per OopsNerv und im Programm miteinander vergleicht (selbes Statement). STRSQL liefert meist den ersten Satz am schnellsten, im Programm wird meist auf Folgeverarbeitung optimiert (z.B.: Blockung erfordert dies oft, um effektiv zu sein!!!)

@runstats:
Runstats können ebensogut in die Irre führen, wie blanke Schätzungen.
(Beispiel: Mandantenkey vom Typ int, Mandant 1 hat 99% aller Sätze
select * from .. where mandant = :mandant) für Mandant 1 wäre full table scan optimal, für mandant2 per index. Ohne runstats kommt unabhängig vom Mandant der gleiche Zugriffspfad raus (wohl index!). Mit runstats kanns klappen, könnte aber sogar für Mandant 2 ein full table scan rauskommen, je nach vorher abgefragten Daten, was aber fatal wäre.
BTW: das wäre eigentlich ein klassischer Kandidat für EVI, wenn nicht...

@Evi:
ein reines Dummy Feature!!! Ich habe noch nie die Benutzung eines EVI erlebt!!! aber Empfehlungen beim schreiben löschen nachher neu aufbauen gefunden - lachhaft, dauert Stunden. War vielleicht mal gut gemeint (ähnlich extended dynamic package support), sollte man besser vergessen!!! Oder hat jemand wirklich ein nachvollziehbares Gegenbeispiel???

@SQE - CQE:
ich habe nix gegen den rewrite, der war absolut notwendig und ist in Summe von Vorteil, hat uns aber seit V5R2 eine ungewohnt launische Datenbank mit unzähligen Bugs beschert und ich halte es für absolut erforderlich solche Dinge öffentlich anzuprangern, damit es besser wird!!!

D*B