Subject | Re: SELECT COUNT(*) ... - slow |
---|---|
Author | rhollay |
Post date | 2002-04-06T08:13:40Z |
Hi Doug,
The count(*) operations COULD BE very frequent.
If you don't want to enable the user to browse through a big table
with millions of rows (slow network, browser-type application),
you could force the user to enter a WHERE criteria to reduce the
result set. The server performs a count(*), and if
the result set is still too big, the user could get a message to enter
a more restricting criteria.
You must perform a count(*) before every new fetching.
If count(*) performs slowly, this can be very tiresome for the user.
Regards, Zoli
The count(*) operations COULD BE very frequent.
If you don't want to enable the user to browse through a big table
with millions of rows (slow network, browser-type application),
you could force the user to enter a WHERE criteria to reduce the
result set. The server performs a count(*), and if
the result set is still too big, the user could get a message to enter
a more restricting criteria.
You must perform a count(*) before every new fetching.
If count(*) performs slowly, this can be very tiresome for the user.
Regards, Zoli
--- In ib-support@y..., Doug Chamberlin <DChamberlin@A...> wrote:
> 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?