Prefetching/Caching of messages should perhaps be a concern of a caching wrapper, not of the engine

[hjohn]

This issue contains three concerns:

• The Postgres engine queries currently up to 50 messages that match a given set of criteria. Due to the nature of the engine interface, it will be hard to externalize this in a generic caching component that can wrap an EventStorageEngine.

• Caching of message ranges should also be possible as messages are immutable, which may be another concern better packed into a wrapper.

• The prefetching in Postgres may find that there aren't 50 messages matching the criteria, but their consumption speed may be low enough that new messages have arrived in the mean time that match the criteria. Should the implementation do a final check when the last message is consumed, or should it assume no new messages have appeared?

Currently this results in say 5 messages being fetched with a SELECT, and then when the final message is consumed, another SELECT occurs to make sure there are no further matches meaning that in many cases a minimum of two queries is needed to source or stream messages.