From: | Ed Loehr <eloehr(at)austin(dot)rr(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pghackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] NOTIFY/LISTEN in pgsql 7.0 |
Date: | 2000-06-08 14:56:01 |
Message-ID: | 393FB401.9F4BCEE2@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Ed Loehr <eloehr(at)austin(dot)rr(dot)com> writes:
> > Is anyone successfully using the NOTIFY/LISTEN mechanism in pgsql 7.0?
>
> It still works AFAICT. Why, are you seeing a problem?
No. I just hadn't recalled any discussion of it in 6 months and wondered
if it was "bit-rotting". The context was a discussion on pgsql-sql re
how to enable table-based caching of results in a modperl/DBI app. More
specifically, use of NOTIFY/LISTEN to alert the apps when a table had
been changed in order to invalidate cached results dependent on that
table. After a closer look, I'm wondering how it would fit (if at all)
with the mod_perl/DBI API/model. [BTW, I still haven't heard anything to
dissuade me from thinking that server-side shared-mem result-set caching
would be a huge performance win for many, many apps, including mine. I
wish I better understood the lack of enthusiasm for that idea...]
Regards,
Ed Loehr
From | Date | Subject | |
---|---|---|---|
Next Message | Brian E Gallew | 2000-06-08 15:06:39 | index idea for system catalogs |
Previous Message | Don Baccus | 2000-06-08 14:55:51 | Re: Proposal: TRUNCATE TABLE table RESTRICT |