yeah, that lines up with my observations too. it did take a lot of work to iron out the bottlenecks though. khatru badger in particular gets a big score on the ranking because of the way its badger event store just flings events but i bet it fails to always get them in order on a relay that has had old events loaded up after a lot of newer ones. it depends on sequence of events being stored to order the results. orly has a special index to make sure they always are delivered in the explicit order of timestamp, and if you read nip-01, you will see. fiatjaf cheated on that with khatru. and relayer.

Replies (1)

index optimization is crucial… on NFDB 2.1 I have worked on some stuff: - some index size optimizations - move the event header (content stripped + only indexables) into the event store as before it was duplicated across multiple dbs sharing the same eventstore - a faster “exists in any one of these relays” lookup with event stores, that also can return event lifecycle info - better event lifecycle state (NFDB supports a soft-deleted stage, and for large events like follow lists it is inserted in multiple transactions due to FDB size limit) - unified deletion index that can be shared across all relays - unified event state data (encoded with capnp, contains lifecycle + expiration + index version + size + …) - “size” accounting based on any metric - global event cache