|Subject||Re: [Firebird-Architect] Inexact database operations|
> This is fine for an entire table; the problem is applying it to aIt is still the part of efforts the optimizer takes to choose the join order
> filtered resultset. I can't see how to efficiently count records (even
> imprecisely) without materializing them; could it be done?
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
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.