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

Joshua D. Drake jd at commandprompt.com
Sat Jun 1 03:37:46 JST 2013


On 05/30/2013 12:28 AM, Tatsuo Ishii wrote:

> 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.

I am not sure I agree with this assessment. Query execution time is what 
it is, it may be 10ms or 5000ms. What I am looking at is the total 
overall parsing time against the velocity of the transactions being 
executed. If parsing is taking 250ms (just as an example) and I am 
pushing 1000 tps, then I have a metric worth improving. That isn't 
taking into account the CPU cycles that add up with that level of 
velocity and parsing.

My goal is very pointed. I am only interested in pgpool-ii for load 
balancing and or connection pooling. All the other features although 
useful are not useful to me or my customers and I find them overhead. 
This is why I am looking for specific ways to make those exact two 
things as efficient as possible.

> 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.

I think we are considering different things. It may not be a big deal in 
the scope of executing the query but it is a big (or potentially a big 
deal) deal in the scope of the system and its utilization.

>
>>> 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?

7K concurrent? That is fairly large. I believe we only have 1 or 2 
customers that would need that level of concurrency to the database 
itself. I would wonder what type of system would need that level of 
concurrency to the database itself.

Sincerely,

Joshua D. Drake


-- 
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
    a rose in the deeps of my heart. - W.B. Yeats


More information about the pgpool-general mailing list