Vitor Pamplona on Nostr: Yes, good catch. My original post was wrong. The 255 nanoseconds is just one query ...
Yes, good catch. My original post was wrong. The 255 nanoseconds is just one query for user+relay pair.
So, to recap:
I have 1M random keys. I got a list of 2000 relays that exist today and randomized 5 relays for each key. That's the DB.
Now, the filter is a regular 10MB 5-step MurMur3 Hash.
To add all those key-relay pairs to the filter takes 1sec.
The indexer keeps a list of all unique relay uris -> 2000 relays. And it uses their position in the list as an extra salt to the Bloom.
To query a given user and return a list of relays the indexer loops through all 2000 relays and runs the query on the filter.
And that takes 321 *micro*seconds.
So, to recap:
I have 1M random keys. I got a list of 2000 relays that exist today and randomized 5 relays for each key. That's the DB.
Now, the filter is a regular 10MB 5-step MurMur3 Hash.
To add all those key-relay pairs to the filter takes 1sec.
The indexer keeps a list of all unique relay uris -> 2000 relays. And it uses their position in the list as an extra salt to the Bloom.
To query a given user and return a list of relays the indexer loops through all 2000 relays and runs the query on the filter.
And that takes 321 *micro*seconds.