> On Mon, Nov 14, 2011 at 5:11 PM, Thomas Steinmaurer <t...@iblogmanager.com > <mailto:t...@iblogmanager.com>> wrote: > > > Ok, but is there a way then to tell how many pages have been fetched > from the cache as the number above for fetched is more likely > "referenced" and not real number of pages fetched from memory? > > > Pages aren't fetched from cache. Once a page is in cache, data is > fetched from it. Sometimes the data is a record, to be expanded into a > record buffer, sometimes it's an index node, sometimes it's a page > number from an offset on a pointer page, or the state of a transaction > from a TIP, or ... > > > I guess the same applies to MON$IO_STATS.MON$PAGE_FETCHES? If so, isn't > comparing MON$PAGE_READS with MON$PAGE_FETCHES a bit misleading if one > wants to check to possibly increase the database page buffers? > > > It's more misinterpreted than misleading. You would never increase the > number of pages in the cache to reduce the number of fetches.
I would expect to reduce the number of (physical) reads when increasing the cache. It would be also interesting if "reads" exposed in various places (isql, monitoring tables, trace api) are pure physical reads from disk and/or fetched from the OS file system cache. I guess, it could be also from the file system cache, because I've seen situations where execution time is larger for the same number of physical reads for a newly established connection, which then decreases for sub-sequent execution of the same statement with an equal number of reads. Regards, Thomas > In an > ideal world, the number of fetches would be enormous and the number of > reads would be /infinitesimal, meaning that all most every request was > resolved from cache and therefor the cache is big enough. The only ways > (I can think of at the moment) to reduce the number of fetches are to do > less work, or work more efficiently (e.g. don't do a count (*) on a big > table)./ > > > Cheers, > > Ann > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
