| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
| Cc: | 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-09 01:45:54 |
| Message-ID: | 20180509014554.GA26879@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 09, 2018 at 09:04:04AM +0900, Tatsuo Ishii wrote:
> I have simulated the idea and I wonder how to implement the query
> result cache on the streaming standby servers because no DML/DDL are
> executed on standby servers, that makes it impossible to invalidate
> the query cache. Probably the only way to allow to use the query cache
> is,
>
> 1) Let invalidate the query cache on the primary server.
>
> 2) The cache storage needed to be on the external cache server like
> memcached.
Or a hook within the REDO loop which can be processed for each record?
You could take any actions needed with that by tracking mostly heap
records.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2018-05-09 02:06:45 | Re: [HACKERS] path toward faster partition pruning |
| Previous Message | Tatsuo Ishii | 2018-05-09 00:04:04 | Re: Having query cache in core |