Vadim Mikheev <vadim@krs.ru> writes:
> I agreed that there is no way to get accurate estimation for
> # of rows to be seen by a query...
> Well, let's keep up-to-date # of rows present in relation:
> in any case a query will have to read them and this is what
> we need to estimate cost of simple scans, as for costs of
> joins - now way, currently(?) -:(
The optimizer is perfectly happy with approximate tuple counts. It has
to make enough other guesstimates that I really doubt an exact tuple
count could help it measurably. So updating the count via VACUUM is an
appropriate solution as far as the optimizer is concerned. The only
good reason I've ever seen for trying to keep an exact tuple count at
all times is to allow short-circuiting of SELECT COUNT(*) queries ---
and even there, it's only useful if there's no WHERE or GROUP BY.
As far as I can see, keeping an exact tuple count couldn't possibly
be worth the overhead it'd take. Keeping an exact block count may
have the same problem, but I'm not sure either way.
regards, tom lane
