Hi<br><br>Thank you for your help.<br><br>We have set up the 3.2 version with your recommended settings (increased relcache_size) and it worked beautifully. It also stopped crashing which is also great!<br><br>Thanks again.<br>
Regards A.<br><br><div class="gmail_quote">On 21 August 2012 16:03, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Hello all,<br>
><br>
> We are considering using pgpool in our small production server<br>
> environment. So far so good, we have successfully set up streaming<br>
> replication and put pgpool on top of it.<br>
><br>
> All the tests seems to be ok however when viewing postgres log files<br>
> (set to logging 'all') we have noticed that pgpool constantly creates<br>
> lots of queries of the following syntax:<br>
><br>
> SELECT count(*) FROM pg_catalog.pg_class AS c WHERE c.oid =<br>
> pgpool_regclass('table_name') AND c.relpersistence = 'u'<br>
> SELECT count(*) FROM pg_catalog.pg_class AS c WHERE c.oid =<br>
> pgpool_regclass('some_other_table_name') AND c.relpersistence = 'u'<br>
> SELECT count(*) FROM pg_class AS c, pg_namespace AS n WHERE c.relname<br>
> = 'another_table_name' AND c.relnamespace = n.oid AND n.nspname =<br>
> 'pg_catalog'<br>
><br>
> With every "our" application query there is more of the above. We also<br>
> noticed that out application is slightly (300ms-400ms) slower with<br>
> pgpool compared to the application going directly to the database<br>
> server.<br>
><br>
> Is the above behavior of pgpool normal or do we need to change<br>
> anything in our configuration?<br>
<br>
</div>Yes, normal. pgpool needs to obtain catalog information from<br>
PostgreSQL. Those query results are cached per connection cache. So<br>
as long as the connection cache remains, the quries will not repeat<br>
again, thus performance will be getting better in the long run.<br>
<br>
BTW, if you use lots of tables, you might want to increate<br>
"relcache_size". Also if you are sure that you do not use temp<br>
tables, you can turn off:check_temp_table and you can skip the query<br>
to check if the table is temporary or not.<br>
<div class="im"><br>
> We also have wierd problem with pgpool 3.2. It crashes after<br>
> succesfull first query. We belive the reason for it is that pgpool<br>
> creates another main process of pgpool. Did anybody have similiar<br>
> issue? Version 3.1.3 is absolutely fine...<br>
<br>
</div>We have found two crash cases with 3.2.0 and fixed them at this<br>
point. I cannot tell if your crash is one of them or not without<br>
knowing details, such as back trace or self contained test case<br>
though.<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div><br>