Subject Re: [ib-support] SELECT COUNT(*) ... - slow
Author Woody
From: "Tobias Giesen" <tobias_subscriber@...>
> > Of course, it "could" be done. Anything can
> > be done. But at what cost?
> Shouldn't be too expensive in terms of man or woman-hours.

It's not always the time to code it that matters. What about the additional
processing time on the server for each record added/deleted.

> > 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?
> Yes.
> BTW might this not facilitate displaying nice, correct,
> proportional scroll bars? This basic, essential UI element
> seems still not to be supported by most C/S set-ups - or
> is it just IBO?

Tobias, although I tend to agree with you about getting and using the counts
of records because I frequently must provide feedback to the users regarding
how many records match their filtering criteria, I don't think it's a wise
idea to make the engine do the additional work of storing the counts since
you can't store them for all given situations. In most cases, it will still
have to do a physical count. I lean more towards improving that counting
mechanism but don't know if it can be improved upon since I don't know the

Also, AFAIK, IBO uses two kinds of record counts, one is a best-guess
scenario and the other will actually do a fetchall, IIRC, to get the actual
count. I believe that is the way that Jason has described it in the past but
with my memory, I could very well be wrong. In any case, it's not hard to
modify grid components to provide the correct positioning of the scroll bars
but that's not a topic for this newsgroup.

Woody (TMW)