On Sat, Oct 23, 2010 at 2:28 AM, Dustin Sallings <dus...@spy.net> wrote:
> > On Oct 22, 2010, at 15:12, Max Vlasov wrote: > > > As for your initial question, I think fragmentation evaluation is > possible > > with the help of VFS. I'd keep a total sum of of absolute difference > between > > consequent read offsets for xRead operation. In this case if some xRead > > request reads 1024 bytes at the 4096 offset and the next xRead reads > > something at 5120 (4096 +1024) this will add 0 to the sum, but if the > next > > read something at 8192, this will add 3072 = (8192 - (4096 +1024)). If > this > > implemented, you will be able to see how this value changes for some of > your > > SELECT and maybe evaluate it on per record basis. If it's more like some > > threshold value, ok, peform VACUUM > > > This sounds like a *really* awesome idea. I know exactly what > operations I'm doing that *shouldn't* generally seek and I can keep some > stats on that. > > Just thought that we should take also sqlite internal cache into account since if the page is cached there won't be reading for the records from that page and it can affect the logic of the evaluator, so the algorithm should track also the total size of the reading. I don't know whether it worth or not but maybe some future version of sqlite would provide us with vfs counters (statistics) in some form (sqlite4_vfscounters?). At least read/write * seek/size counters would be useful. Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
