Cache invalidation notification (was: Database Caching)

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

In response to

Responses

Browse pgsql-hackers by date

  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