Until your code starts fetching rows, you don't have any. A query can take a long time to execute yet still return few rows. For example, count(*) on billions of rows will take some time. Yet it only returns one row. If you cancel before the scan is complete Oracle doesn't know the answer, so can't return anything.

As soon as you're in the fetch phase you can stop processing whenever you want (how you do this and show it to the user in your environment is something you'll need to figure out).

I stand by my comment on TopN queries though. It's rare people want or need to see more than 10-20 results at a time. Implementing a Top-N query will do this for you and often result in faster query execution too.

I think this is an appropriate followup to the original question. No need to raise a new one.

I don't see how this helps. The count still needs to process the entire query before it can show how many there are. So in the billion row example, there's still a delay before there's anything to return to the client.