Re: Sending notifications from the master to the standby
От | Josh Berkus |
---|---|
Тема | Re: Sending notifications from the master to the standby |
Дата | |
Msg-id | 4F0E2076.1030002@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Sending notifications from the master to the standby (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Sending notifications from the master to the standby
|
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: