Thanks Sayan. I experimented a bit with the test code making 'a' the PK, and
could see the underlying PK index use, but was still exceptionally surprised
with the query cost and row estimates. I hadn't considered that row limiting
in this sense was just some sort of 'syntactic sugar' (your words) for some
internal transpiler to rewrite the code using an analytic function. Looking at
the plan however, it seems quick obvious now, especially the filter
ROW_NUMBER() OVER ..... In my code, this is a 12c new feature that performance
implications will mandate I just do not use.