> The big concern I have about memcache is that because it controls
> storage external to the database there is no way to guarantee the cache
> is consistent with the database.  This is similar to sending email in a
> trigger or on commit where you can't be certain you send email always
> and only on a commit.

Well, some things ... ON COMMIT triggers, or messages with NOTIFY, would 
improve the accuracy by cutting down on cached aborted transactions.  

However, caching is of necessity imperfect.   Caching is a trade-off; greater 
access speed vs. perfect consistency (and any durability).    There are cases 
where the access speed is more important than the consistency (or the 
durability).   The answer is to use memcached judiciously and be prepared to 
account for minor inconsistencies.    

For that matter, as with other forms of cumulative asynchronous materialized 
view, it would be advisable to nightly re-build copies of data stored in 
memcached from scratch during system slow time, assuming that the data in 
memcached corresponds to a real table.  Where memcached does not correspond 
to a real table (session keys, for example), it is not a concern at all.

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to