[Pgpool-hackers] About query cache of pgpool-II

Tatsuo Ishii ishii at sraoss.co.jp
Thu Oct 13 01:03:40 UTC 2011


>> Yes, it's on my TODO list. However, there is a fundamental difficulty
>> to implement it. For performance reason, to return cached result or
>> not is decided *before* SQL parsing. Problem is, without SQL parsing
>> it's not possible what tables are involved in the SELECT (think about
>> complex JOIN or subquery).
>>
> 
>> Delaying the decision after the parsing will add an overhead.
> 
> Can you tell me a little more detail about the implementation of the
> cache function.
> I guess the cache cached the result of a query. So I think just a
> simple compare is
> enough to check if this query is executed before. Maybe it may wast some memory
> because sql is not case sensitive and maybe 2 sql actually is the same
> while strcmp
> tell us that they are not. If the result of sql is cached, just return
> result. If not, do parse,
> check if the the tables in white/black list and query data.

Oh I was wrong. Yes, we can check if the tables included in the SELECT
can be cached or not *after* parsing.

We can have something like:

memqcache_cache_tables:
List of table names allowed to cache. Regular expression can be used.

memqcache_no_cache_tables:
List of table names not allowed to cache. Regular expression can be used.

They are exclusive like black/white_function_list.

Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


More information about the Pgpool-hackers mailing list