[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