Subject RE: [ib-support] SELECT COUNT(*) ... - slow
Author Paul Schmidt
On 5 Apr 2002 at 19:02, Doug Chamberlin wrote:

> 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?
>

They aren't and they don't, this only needs to be in an engine that doesn't handle
triggers properly, where the engine handles triggers properly (like Interbase does)
then it's simple enough to do it within the application.

PaulPaul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com