Subject | RE: [ib-support] SELECT COUNT(*) ... - slow |
---|---|
Author | Paul Schmidt |
Post date | 2002-04-06T15:48:09Z |
On 5 Apr 2002 at 19:02, Doug Chamberlin wrote:
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
> At 04/05/2002 06:21 PM (Friday), Tobias Giesen wrote:They aren't and they don't, this only needs to be in an engine that doesn't handle
> > > 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?
>
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