From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rod Taylor <rbt(at)zort(dot)ca>, Hannu Krosing <hannu(at)krosing(dot)net>, Dann Corbit <DCorbit(at)connx(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Cache invalidation notification (was: Database Caching) |
Date: | 2002-03-05 07:45:26 |
Message-ID: | 1015314331.1933.25.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2002-03-04 at 23:50, Tom Lane wrote:
> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > Rather than result caching, I'd much rather see an asynchronous NOTICE
> > telling my webservers which have RULES firing them off when a table is
> > modified.
>
> LISTEN/NOTIFY?
But is there an easy way to see which tables affect the query result,
something like machine-readable EXPLAIN ?
Another thing that I have thought about Is adding a parameter to notify,
so that you can be told _what_ is changed (there is big difference
between being told that "somebody called" and "Bob called")
There are two ways of doing it
1) the "wire protocol compatible" way , where the argument to LISTEN is
interpreted as a regular expression (or LIKE expression), so that you
can do
LISTEN 'ITEM_INVALID:%';
and the receive all notifies for
NOTIFY 'ITEM_INVALID:' || ITEM_ID;
and
NOTIFY 'ITEM_INVALID:ALL';
where the notify comes in as one string
2) the more general way where you listen on exact "relation" and notify
has an argument at both syntax and protocol level, i.e
LISTEN ITEM_INVALID;
and
NOTIFY 'ITEM_INVALID',ITEM_ID;
NOTIFY 'ITEM_INVALID','ALL';
------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-03-05 07:51:34 | Re: Storage Location Patch Proposal for V7.3 |
Previous Message | Tom Lane | 2002-03-05 07:30:07 | Re: Storage Location Patch Proposal for V7.3 |