I don’t think we have noticed bottleneck on filter service node. There were issues in the way filter client side was implemented/used in status-go which was causing issues wrt subscriptions such as taking time to subscribe and out of order subscribe and unsubscribe etc. iirc batching subscriptions on client side helped solve these issues.
The main issue with content-topics was store performance and ofcourse the usage did not match filter criteria which it was intended for. This was the post which shows the issues.
Yes, just create a new bloom filter locally without those subscription and “re-subscribe”.
aka, service node only has 1 or 0 bloom filter for you. So whenever you “subscribe” you create or override a bloom filter.
unsubscribe is an override.
unsubscribe_all deletes the bloom filter.
But it seems that it was not an issue so we may not have as much as of an upper bound on content topic as we thought then? As long as we reduce store time range queries (aka, not 24 hours queries * 30, but maybe 1 hour queries, etc.