Subject RE: [ib-support] SELECT COUNT(*) ... - slow
Author Doug Chamberlin
At 04/05/2002 06:21 PM (Friday), Tobias Giesen wrote:
> > And the reason it doesn't, is that there may be
> > different numbers of rows for different concurrent
> > transactions.
>
>So what? It could maintain separate counters for each
>transaction, as well as a main counter for the committed
>rows. I'm sure it could.
>
>However, this optimization feature doesn't seem to have
>been considered worth it.

Nor have I seen anyone make a sales pitch for it now.

Of course, it "could" be done. Anything can be done. But at what cost? Are
count(*) operations that frequent or that critical or that sub-optimal that
a special case needs to be added to the engine to optimize them?