15.11.2011 2:11, Thomas Steinmaurer wrote: > > 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?
I bet you're thinking about the "cache hit ratio" which is commonly used to estimate the cache efficiency. It's usually calculated as (1 - physical reads / logical reads). In the Firebird case (logical reads = fetches and they're mostly record-level) this metrics always gets overestimated and thus practically useless. In order to have a workaround, I was thinking about an additional counter "adjacent fetches" - number of fetches belonging to the same page which is subsequently accessed by the same retrieval, i.e. kinda "redundant" fetches that turn the supposedly page level counter into the record level one. So the formula could be changed to something like: 1 - reads / (total fetches - adjacent fetches) thus resulting to a more realistic estimation. The fact that data page fetches are intermixed with pointer page fetches during the retrieval makes the calculation not so trivial but it this still looks possible. The question is whether there's actual demand from our users / DBAs. I know this is a quite popular performance tuning metrics in other databases but so far nobody complained on the our side ;-) Dmitry ------------------------------------------------------------------------------ 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
