this discussion makes me think of something too... so, i already have a simple size-related caching strategy implemented, it runs on a timer and trims down the database when it gets to a certain size and trims it back to a second size (high and low water marks)

it might be an interesting addition to the cache prune heuristic to selectively prefer to remove entries that have few inbound references, ie, the less engagement, AND the more stale (last accessed timestamp) combined would be a good heuristic for pruning not just stale events but irrelevant events, which are going to largely be botfarms

Reply to this note

Please Login to reply.

Discussion

it would require a second ticker for doing inbound reference counting and adding a new index that keeps track of this so when the GC runs it only has to check the inbound count index alongside the most recent access time

i am up to a stage of optimization with replicatr... this could well be very useful thoughts for future reference

made some notes about this and another optimization i have got in mind after this chatter

https://github.com/Hubmakerlabs/replicatr/issues/38

https://github.com/Hubmakerlabs/replicatr/issues/39

#nostr is so awesome for free-wheeling discussions about nostr engineering