> Yeah, upthread Simon pointed out that propagating notifies would be > useful for flushing caches in applications that watch the database in a > read-only fashion. I grant that such a use-case is technically possible > within the limitations of a slave server; I'm just dubious that it's a > sufficiently attractive use-case to justify the complexity and future > maintenance costs of the sort of designs we are talking about. Or in > other words: so far, cache invalidation is not the "first" use-case, > it's the ONLY POSSIBLE use-case. That's not useful enough.
Well, cache invalidation is a pretty common task; probably more than 50% of all database applications need to do it. Note that we're not just talking about memcached for web applications here. For example, one of the companies quoted for PostgreSQL 9.0 release uses LISTEN/NOTIFY to inform remote devices (POS systems) that there's new data available for them. That's a form of cache invalidation. It's certainly a more common design pattern than using XML in the database. However, there's the question of whether or not this patch actually allows a master-slave replication system to support more Listeners more efficiently than having them all simply listen to the master. And what impact it has on the performance of LISTEN/NOTIFY on standalone systems. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers