On Oct 28, 2005, at 7:20 PM, SRS wrote:
Edward Wilson wrote:
The idea of issuing two selects is, well, a hack, and knowing how
many records one has in a
result-set is a powerful feature
Are you needing a progress bar for the search (ie the query?) Or some
action based on the result set? If the later, get the result set as
your favorite container.. ask the container the size. If its the
first then a "feature" won't help. It still has to 'run' the query in
order to get the count. It would be like me asking you to tell me how
many red Skittles are in a package before you open it. As for being a
'hack' .. all your 'feature' would be is a pretty programming
interface around that hack. As I said before, how can the database
know the number of items that will be returned without first searching
for them.
I think the problem is not so much (at least IMHO) that two queries
have to be performed (that itself is a reasonable expectation), but
that the COUNT(*) query is likely to be slow because of the full table
scan. One option is to use an aftermarket solution... for example, in
my Perl applications once I have queried the db for the columns based
on my criteria, I simply count the number of elements in my record set
thereby avoiding a double query to the database. Although, in reality,
I personally don't mind the COUNT(*) option... none of my databases are
that large to merit worrying about this.
