>
> Hmmm, this message is one month old, howerver I believe I was thinking
> of tables having
> fixed length records, like dBase, Access, I don't know about others.
Ah, yes, for fixed length records it allows for a lot of shortcuts.
> Also, the b-tree or other algorithms used in idexes implie that they
> know the number of records.
They might know the number of records in physical storage, but that does not mean that they can use that number to answer a count query.
> In other databases, I don't know where it is, but if they don't have
> such a feature, I wonder
> why it is worth paying so much to have them ;-)
Is the speed of count(*) how you measure the value of a database?
>>Why must it do so? Isn't that a lot of overhead?
>
> A lot of overhead to maintain a 4 bytes count in a many megs file ?
> C'mon ;-)
I am not talking about storage space, but about concurrency and atomicity.
If I have 200 simultaneous connections that means 200 simultaneous transactions which means 200 different numbers. For each table.
Keeping those numbers correct would be far from trivial without effectively single-threading your table access.
Jochem
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
