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

[Tatsuo Ishii]

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

I would say 250ms for parsing is never possible. PostgreSQL's parser
is devided into two parts: raw parser and planner (optimizer). Planner
could takes much time if query is complex (typical case is many way
joins). 250ms is not unsual. However the raw perser is just do a
parsing, which should not never take much time. Pgpool only uses raw
parser, which should never take much time.

BTW, Postgres-XC has its own parser as well. The difference is, it has
not only the raw parser, but the planner. So I guess the overhead of
Postgres-XC is more than pgpool.

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

An attempt to optimize parser or connection pooling is always welcome.
However I cannot think of any way to implement the load balancing
without having a raw parser.

For some special cases, we could avoid parsing as we discusses in
pgsql-hackers list, though.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

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