> On 07.05.2018 05:32, Tatsuo Ishii wrote: >> Does anybody think having in-memory query result cache in core is a >> good idea? From the experience of implementing the feature in >> Pgpool-II, I would think this is not terribly hard job. But first of >> all I'm wondering if there's a demand for the feature. > > Do you want to implement this cache locally in backend?
No, as a global cache, if I employ the design of Pgpool-II. Pgpool-II offsers two types of query result cache: in the shared memory or using external cache server (i.e. memcached). > Global result cache (like one used in mySQL) may be more efficient. > But I think it is better to start first with > 1. Global prepared statements cache > 2. Global catalog cache > 3. Global relation cache Are they totally different story from query result cache, no? > Concerning result cache, I think it will be better to ask opinion of > mysql users: how useful it is. One RedShift user used to use the query result cache in Pgpool-II (I think they moved to more application layer cache). So I just wonder if there is any demand for in-core cache. I think one merit to have it in-core is, it's easy to get catalog info: Pgpool-II works hard to figure out if the query result is safe to cache or not. e.g. the SELECT uses stable functions or not, uses temp tables or not. In-core cache eliminates the hard work (no need to say cache invalidation). On the other hand, query cache definitely avoid heavy SELECT run twice, but user need to connect to PostgreSQL if it's in-core. Having query cache in the middle ware like Pgpool-II could completely avoid accessing PostgreSQL. Anyway, I already have a query cache in Pgpool-II. So unless users are eager to have it in core, I will not be so interested in implementing it. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp