On Mon, Jul 30, 2018 at 11:42 AM Eric Grange <egra...@glscene.org> wrote:
> PtrMap pages may be too much overhead in my case, I have occasionally run > vacuum on same databases to see the effect, and it was not very > significant. > > This is likely because the databases are heavily skewed towards inserting > (and indexing) data than about update/delete, and while the tables are > quite fragmented, > since I am using SSDs, the gains from a vacuum defragmentation appears > marginal. > I was merely suggesting that, if the overhead of PtrMap pages (i.e. using auto-vacuum or incremental-vacumm), in terms of added disk-space (for those extra-pages) and extra processing, is acceptable to you, they likely could lead to a (much?) faster how-many-DB-pages per table or index than dbstat. Depends how important it's to you to getting those pages-per-table stats faster than dbstat gives them to you. At the expense of you having to code it ourself of course. Ideally, dbstat would also have be able to use PtrMap as well, to speed up that query. But since it does much more than giving you that page-count, maybe it's not practical. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
