The reason being that to implement the proper isolation semantics expected by a standard COUNT it needs to somehow iterate all data; fetching it at the same time only adds a small additional cost which often is negligible. So we do that first, and then repeat again for the itaration.. doubling the total time it takes just to have a reasonable estimate half way - we could be done by that time.

I doubt finding and fetching a million rows over the network would cost the same as finding them and just returning the count... Especially when not using any WHERE clause, or when relying on database indexes in the WHERE clause.
But I agree the extra cost may bother some users, so let's not force it on them.

When thinking about these evolutions, I think we need to take into consideration an alternative approach which skips the count altogether - for many of my personal experiments I regularly find myself commenting out some code, obvsiouly there could be better alternatives.

Right... Two ideas (non-exclusive):

• we could just skip unnecessary counts when no monitor is provided by the user
• we could, as I suggested in the ticket description, add switches so that users select the "monitoring strategy" explicitly.