The long term plan is to make so that a result only has to query in 2 cases, opening and refresh. All the other cases should be handled through notifications. That would allow potentially asyncifying any kind of result, by freezing the result and the view while the query runs.

This should analyze which information is currently used by VisitIdToResultNode, URIToResultNode, BookmarkIdToResultNode that is not provided by the new notifications, and evaluate how expensive it would be to fetch and add such info to the notification.

Next step after VisitIdToResultNode, URIToResultNode, BookmarkIdToResultNode are done would probably be to check if we can avoid querying in NotifyIfTagsChanged.

Daisuke, I started looking into this last week to understand how complex it is. It won't be trivial, thus I think we should split the work into multiple bugs, likely one per method.
BookmarkIdToResultNode seems to be the easiest start point and I have a very rough start patch you can import and work with. Please let me attach what I have, also to clarify what I had in mind.

Note the patch is very incomplete. One main concern will be fetching tags, though we can probably limit that to bookmark queries and likely not all the notifications need them, adding a bookmark needs tags, moving or removing should not.

Thank you very much for your help, Marco!
It is so helpful.
I will split this bug into (maybe) 3, then fix them.
(Another new Jira ticket it seems that we better to do asap came today, please let me start this after that)