x wrote: > Why would window’s increase it’s cache size during step ascending then > reduce it during step descending in such a consistent manner?
Windows has several different caching strategies. <https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858.aspx> says: | FILE_FLAG_RANDOM_ACCESS | | Access is intended to be random. The system can use this as a hint to | optimize file caching. | | FILE_FLAG_SEQUENTIAL_SCAN | | Access is intended to be sequential from beginning to end. The system | can use this as a hint to optimize file caching. | | This flag should not be used if read-behind (that is, reverse scans) | will be used. | | If none of these flags is specified, the system uses a default general- | purpose caching scheme. SQLite does not specify these flags. Apparently, the default general-purpose caching scheme tries to detect what access pattern the application uses. The rows are stored in rowid order in the file, so the ascending scan looks as if it might be a sequential scan. This means that Windows will prefetch following data, but it does not know if some data will be read again later, so it will keep the data in the cache. The descending scan looks like a reverse scan. By that point, Windows probably assumes that you are definitely using sequential scans, so it thinks the data can be thrown out of the cache after you've read it. Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
