| 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 12:26:42 |
| Message-ID: | 20180511.212642.348816986505361564.t-ishii@sraoss.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Thanks for the advice. But I rather thought about bypassing the raw
>> parser and the planner. i.e. use the query string (or its hash) as the
>> index of the query cache.
>>
>
> 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)
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 | Vladimir Sitnikov | 2018-05-11 12:33:05 | Re: Having query cache in core |
| Previous Message | Konstantin Knizhnik | 2018-05-11 11:58:03 | Re: [HACKERS] Surjective functional indexes |