| From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | cktan(at)vitessedata(dot)com |
| Cc: | ishii(at)sraoss(dot)co(dot)jp, hlinnaka(at)iki(dot)fi, 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:18:30 |
| Message-ID: | 20180512.071830.919721368413960369.t-ishii@sraoss.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> > I think you need to know which tables are involved and if they were
>> > modified.
>>
>> Of course. While creating a cache entry for a SELECT, we need to
>> analyze it and extract tables involved in the SELECT. The information
>> should be stored along with the cache entry. If any of the tables were
>> modified, cache entries using the table must be removed.
>> (these are already implemented in Pgpool-II's in memory query cache)
>>
>
> 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.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | CK Tan | 2018-05-11 22:20:13 | Re: Having query cache in core |
| Previous Message | Tatsuo Ishii | 2018-05-11 22:13:56 | Re: Having query cache in core |