[pgpool-general: 829] Re: Documentation Questions

Tatsuo Ishii ishii at postgresql.org
Tue Jul 31 14:15:15 JST 2012


> Up until now, I have only considered lighter weight connection
> poolers, but with 3.2's more transparent memory query cache, pgpool-II
> has suddenly become my primary interest for new deployments.  It looks
> like it it should work well with all open source projects that only
> use basic DML (no triggers, SPs, or update'able views).  I am
> specifically thinking about MediaWiki and Drupal.
> 
> I was reading through the documentation for pgpool-II-3.2.0-RC2 and
> found a 3 things:
> 
> 1) Documentation: "On memory cache saves pair of SELECT statements
> (with its Bind parameters if the SELECT is an extended query)."
> 
> I am not familiar with its design, but would think that the actual
> pair is the select statement (with bind parameters if applicable) and
> the accompanying result set.  The sentence implies that there are two
> SELECT statements per cache entry.  I do not see what a second SELECT
> statement would be for.

No, we create a string concatinating a SELECT and bind parameters
reprsented in hexa dicimal string. For example, "SELECT * FROM table
WHERE i = $1" and $1 (bind parameter) = 1, then the cached SELECT
statement would be someting like

"SELECT * FROM table WHERE i = $1 00010001"

> 2) Does black_memqcache_table_list also blacklist tables if the
> memqcache_method is shmem?

Yes.

>  The name implies that it only operates
> with the memqcache method.  In which case, the shmem method appears to
> not have table blacklist functionality.  If that is the case, maybe it
> is worth mentioning that memqcache has this exclusive advantage in the
> documentation.

The word "memqcache" comes from "on memory query cache". It actually
includes both shmem and memcached method. So many of directives
including black_memqcache_table_list can be applied to both shmem and
memcahed.

Commonly applied to both shmem and memcached:
memory_cache_enabled
memqcache_method
memqcache_expire
memqcache_auto_cache_invalidation
memqcache_oiddir
memqcache_maxcache
white_memqcache_table_list
black_memqcache_table_list

Only applied to shmem:
memqcache_total_size
memqcache_max_num_cache
memqcache_cache_block_size

Only applied to memecached:
memqcache_memcached_host
memqcache_memcached_port

> 3) Documentation under Restrictions \ Query Cache:
> "Currently, the query cache must be deleted manually. pgpool-II does
> not invalidate old query cache automatically when the data is
> updated."
> 
> This sounds like it only applies to versions 3.1 and earlier.  Do you
> really have to manually invalidate for version 3.2 and later?

Oh, that should be updated. The sentence was only applied to the old
on disk query cache system.  Of course new on memory query cache has
auto cache validation system.

> I noticed that you use MediaWiki with PostgreSQL 9.0 at
> http://pgpool.net/mediawiki/.  Assuming that the query cache works
> with MediaWiki, are you currently testing pgpool-II-3.2.0-RC2 with
> query caching enabled for your MediaWiki install?

No. But of course I am looking forward to testing MediaWiki with on
memory query cache.
--
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-general mailing list