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 > _five_ > 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 > moment. 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 ...
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
