On Mon, March 26, 2007 16:21, Daevid Vincent said:
>> You're about 5 years too late for this converation, but I recall it
> Really? People have just happily accepted this absurd limitation for
> years? Wow.
>> having to do with the fact that when you're on a table that supports
>> transactions, you don't know exactly how many records a particular
>> session has available to it unless you actually go and count them.
>> Depending on your settings, you may or may not see rows inserted by
>> other uncommitted sessions, and they may disappear if the other
>> sessions roll their transactions back.
> You know how many are *IN* the table on the disk at that particular
Why would they be on the disk. Until the transaction is committed and the
caches are flushed the info. is really in memory I thought.
> That's all that needs to be shown!?
> So if someone isn't using transactions, then that number will be accurate.
> This isn't rocket science.
>> You should probably be filing bug reports or calling your support
> Oh. I will. ;-)
>> Let us know if you find another database product that supports instant
>> count(*)'s on transactioned tables.
> I don't care what other RDMS are or are not doing.
> I care what the one I'm paying for is not doing.
If you want to bypass the uncertainties built into transaction tables and
get a count that is 'accurate', how about locking the tables then issuing
the count request. I realize this sort of defeats the purpose of
transaction tables but ...