tatsuo-ishii
commented
5 hours ago [previous example was not appropriate and removed.]
You can create a view and register it to cache_safe_memqcache_table_list.
cache_safe_memqcache_table_list = 'v1'
test=# create table t1(id int, tm text);
CREATE TABLE
test=# insert into t1 values(1, '2024-07-01 20:36:00+0900');
INSERT 0 1
test=# select id,tm::timestamptz from t1 where id = 1; -- this result is not cached because of type cast
id | tm
----+------------------------
1 | 2024-07-01 20:36:00+09
(1 row)
test=# create view v1 as select id,tm::timestamptz from t1; -- create wrapping view
CREATE VIEW
test=# select * from v1 where id = 1; -- this result is cachedA downside of this method is, even if t1 gets updated, query result of v1 does not automatically get updated. You need to execute a "dummy update" (e,g, update v1 set id = 1 where id = 1) or drop/re-create v1.
The documentation says:
I'm facing a use-case with Grafana, where I wish to cache some heavy queries being made on some dashboards. These queries frequently feature timestamps with timezones or somesuch, functions running on timestamps, etc. I'm using pgpool in raw mode for that, as the caching functionality is all I wish to use.
However, despite moving these queries around, there always seems to be some element somewhere or other that triggers the immutability filter in pgpool, and renders the queries I want uncacheable.
Would it be possible to add a configuration toggle for each of the big "categories" of caching exceptions, such that one can bypass this initial filtering? I understand the footguns involved (in particular with non-immutable functions, timestamps with timezones potentially giving different results, ...), but in my specific use case, these do not really matter as there is only one well-known client requesting this information.
Thank you in advance.