Jeremy Bernstein wrote:
Hi,
I may have spoken too soon. I'm now using a 32MB toy database, typical for
my users. I'm pruning at 90% which seems to be about the right number, but… the number of pages in my mdb_stat() isn't reducing. So I'll do a round of pruning, maybe 5% of the records. But the next time I come around to mdb_put(), I have to do it again. Until some critical pruning mass is reached (for instance, I started pruning at 688622 and the pages didn't reduce below 90% until I had pruned down to 389958). My transaction grain is a very modest 50. I've tried closing and reopening the environment just to ensure that everything is fresh, but it doesn't change the stat I'm getting.
Does that make any sense/ring any bells? Thanks again for your help so far.
That's normal for a B+tree with multiple nodes on a page. And if you're only looking at mdb_stat() of the main DB, you're only seeing part of the picture. Again, look at the output of the mdb_stat command line tool. Use "mdb_stat -ef" so you also see the freelist info.
The trick, in your case, is to make sure that the number of free pages is always sufficient, and also the number number of freelist entries. A freelist entry is created by a single commit, and you want to always have at least 3 of them (because the 2 most recent ones are not allowed to be used). If you do all of your deletes in a single commit you will not free up usable space as quickly as doing them in several commits.