> This is fine for an entire table; the problem is applying it to a
> filtered resultset. I can't see how to efficiently count records (even
> imprecisely) without materializing them; could it be done?

It is still the part of efforts the optimizer takes to choose the join order
with the lowest cost. So it has to estimate the number of rows/pages
(cardinality) not only in entire tables but also in their subsets filtered
on conditions. There is statistics on indexes and some euristic knowedge
that helps that. When a join order is generated, the optimizer combines the
cardinalities of participating tables to calculate the entire query
cardinality.

So, after you prepared a query you should be able to ask the optimizer of
how many rows it expect in the outcome based on the plan generated.

Regards,
Aleksey Karyakin