[pgpool-general: 1807] Re: pgpool vs. pgbouncer

[Tatsuo Ishii]

> Well that would easily account for the drop in performance.
> 
> I have been thinking a lot about pgPool lately because we have found
> ourselves deploying it quite a bit. I am curious if there is a way to
> further isolate the various capabilities of the software.
> 
> We never use the replication features but we do use load balancing. I
> would like to find a way to make the connection pooling. and or and
> with the load balancing much more efficient.

Before jumping into the hard work to find out a way to eliminate
the parser, probably you would better to study how heavy each SELECT
query in your applications is. After all, the most important thing is
the ratio between parsing time and query execution time. For example,
if each SELECT consumes 100 times longer time than parsing the SELECT,
whether we could elminate the parser or not is not a big deal.

For example, if you look at page page 22 of this:
http://www.pgecons.org/wp-content/uploads/2013/04/Introducing_PostgreSQL_Enterprise_Consortium_activities.pdf

you will find that pgpool's overhead is not a big deal (because pgpool
is scaling according to the number of nodes) as long as those SELECTs
shown in the slide are involved.

>> BTW, by knowing that pgbouncer's transaction mode is alomost 40%
>> slower than session mode, I noticed what people wants to have is not
>> just throughput, but the ability to allow large number of concurrent
>> connections unless pgbouncers's user rarely use the transaction mode.
> 
> I know that every time we set it up, we only use session
> mode. Obviously we have installed it a lot.

Ok, maybe I had been too much affected by the conversation with
someone in PGCon. He really wanted to handle 7k concurrent
connections. Is this kind of requirements not so usual in your
business?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp