It sounds like a bug for me.

hmm! thanks, I'll go to the proper bug channels then

I don't think so. db-stats is the stats of the index, and there's only one index at a time

as-of, since, etc are just filters on the index

I don't think db-stats could be implemented efficiently if it filtered too

it is a great description for a index-stats function. 👀 The db in the past uses only a subset of the index, so db-stats should respect this subset, imho.

but to do this it has to descend into the "leaves" of the tree instead of just walking the index nodes

you can efficiently give stats for a particular index tier (e.g. all of history, or all of the "now"), but not for subsets of one, which is what as-of/since can do

@U09R86PA4 thanks. Out of curiosity, if you needed to compute the rate of growth of a set of attributes would you use the datoms api or trawl the tx-log? I've implemented my own db-stats using d/datoms that respects as-of+history, but it just takes forever, even though I'm just getting a count for every month the database has been in operation.

I'm guessing that I'm doing a lot of double counting since I'm running the computation for each month. Probably would be more efficient to trawl the tx-log, no?

Depends on exactly what you are measuring and why. If you are just looking at a few attr and are mostly interested in index size or churn or sth like that, I'd d/datoms aevt once over an unfiltered history db and bucket by tx myself. You can compute tx intervals for time using avet of db/txInstant

If you want everything, or you want to include unindexed info (eg noHistory attr churn) I'd use tx range directly

Oh, lordy -- bucket by tx -- I'm embarrassed for not thinking of that! Thanks @U09R86PA4!!!

Hmm. I see -- if I'm using the :aevt approach it's gonna need to be only for a few attributes. Gonna tx-range since I need more of a global snapshot of what business entities (attr sets) with the largest datom footprints are growing fastest.