Clojurians Log v2

Index-range is efficient in that it only reads what you consume out of it. But I don’t get the connection to your second question

they are distinct questions: I was hoping there was a way to count the index size for matching values in an index without materializing it. The second question is about pagination.

What do take while and drop while have to do with counting?

Take the guts of group-by and create a new fn called reduce-by where the rfn is inc

Right, I was hoping there was a way to calculate (or even estimate) the size of matching values in multiple ranges without iterating over each datom in the range. My goal is to show a total count of matching values in an index without looping over every datom in index, which could be large.

To estimate count without reading datoms would have a margin of error of over a thousand

Have you tried index range? Getting a count of a contiguous section of index using index-range/seek-datoms is pretty darn fast

Can you say more about how you determine if a datom's value "matches"? I assume when you said "the size of matching values" you mean "the count of matching values"?

No, only index-pull can read indexes in reverse

it seems that d/index-pull can only traverse the main indices :avet or :aevt, but not tuple indices

“Not tuple indices” what do you mean? Avet and aevt can have tuples in them

There’s no special “tuple indexes”

Index-range is just wrapper for seek-datoms :avet

It’s not special

ah, so the :selector can contain a tuple attr

Yes

But also not sure why that is relevant

Selector is a pull expression

Did you think pull expressions could not have tuple-valued attrs in them?

In my implementation, I'm destructuring the composite tuple value :v value to get at the data I need. Is d/index-pull sophisticated enough to know it can do that, or would it have to hit :eavt with the :e of the tuple attr to pull out the relevant :v?

I believe the impl today performs a separate pull per entry hitting eavt or aevt and doesn’t reuse the value found. However this isn’t significant overhead if you are only taking a single item

It's just postgres, so probably? I'm using it as a transaction log for datascript (persisted to indexed-db, then synced to supabase) in a playground project, but no idea how it will scale.