One of the neat things about Google Mail is that it uses a push architecture. The idea is simple really (the implementation isn't though) youn can infer that people are interested in updates as long as they have asked for data before.
Once you know someone has asked a question or submitted a query, like an html request for a page, you can provide them with up to date diffs or events that can affect the current state of their query. They can figure out what it would be, without actually doing a new query.
This is another form of compression. The assumption of prior knowledge, and assumption of interest.
In games development, when we set up how we're going to do network traffic for multiplayer, normally we initialise a game state, schedule a sync point, then keep each of the players / clients up to date with network events, or sync ups for positioning and other things that are less deterministic.
This same thing can be used in other ways too. Some resource managers remember who's had what off them, and if the resource is updated externally, it get propagated through the system.
There are quite a few other places where this technique works well, but boil it down to its basic component and you've got a query that is kept alive by the data source. The query is the user, and the data source knows about it, and wants to keep it happy and up to date.
This is quite simple, but how often to entities in games "poll" for some world states? Lots! And all of these every frame pollings (apart from the really esoteric ones) can be replaced with live queries. Queries that live past their call and response, get updated whenever anything matters, and can probably self optimise in many cases.
Difficult to syncronise queries like "what is near me" can be made live, by updating the parameters whenever the entity moves.
All this means that senses are more continuous. I'd speculate that it won't help with memory usage by much, but should save CPU time by not creating and destroying queries all the time.