Re: Having query cache in core

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

In response to

Browse pgsql-hackers by date

  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