> 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

Reply via email to