From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | CK Tan <cktan(at)vitessedata(dot)com> |
Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Having query cache in core |
Date: | 2018-05-11 22:32:04 |
Message-ID: | 20180511223204.k6zwd2yyhsvnon6a@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-05-12 08:20:13 +1000, CK Tan wrote:
> On Sat, May 12, 2018 at 8:18 AM, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
>
> > >
> > > How do you handle tables hiding behind views? Also how does cached
> > entries
> > > in pgpools know if some tables are modified without going thru pgpool, eg
> > > pgplsql or trigger or via psql directly?
> >
> > Pgpool-II do not invalidate cache entries for views, triggers and
> > others. That's an limitation of the implementation in Pgpool-II.
> >
> > I think in-core query cache would not have the limitation because it
> > would have a full access to system catalogs and wal.
> >
> >
> Yes. That's my point. You can't do it outside the core.
There's a lot of possibilities between "external daemon" and "in
core". ISTM that it's likely that the current extension API already make
this possible. But if not, it seems like adding the few missing hooks
wouldn't be that much work.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-05-11 22:41:33 | Re: PANIC during crash recovery of a recently promoted standby |
Previous Message | CK Tan | 2018-05-11 22:20:13 | Re: Having query cache in core |