[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