Re: Much Ado About COUNT(*)

On Wed, 12 Jan 2005, Jonah H. Harris wrote:

> Andrew Dunstan wrote:
>
>> Monetary cost is not the issue - cost in time is the issue.
>>
> We seem to be in agreement. I'm looking for faster/smarter access to data,
> not the monetary cost of doing so. Isn't it faster/smarter to satisfy a
> query with the index rather than sequentially scanning an entire relation if
> it is possible?
>
> Replying to the list as a whole:
>
> If this is such a bad idea, why do other database systems use it? As a
> businessperson myself, it doesn't seem logical to me that commercial database
> companies would spend money on implementing this feature if it wouldn't be
> used. Remember guys, I'm just trying to help.

If you're willing to do the work, and have the motivation, probably the
best thing to do is just do it. Then you can use empirical measurements of
the effect on disk space, speed of various operations, etc. to discuss the
merits/demerits of your particular implementation.

Then others don't need to feel so threatened by the potential change.
Either it'll be (1) an obvious win, or (2) a mixed bag, where allowing the
new way to be specified as an option is a possibility, or (3) you'll have
to go back to the drawing board if it's an obvious loss.

This problem's been talked about a lot, but seeing some code and metrics
from someone with a personal interest in solving it would really be
progress IMHO.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...