On 12/07/10 14:15, A. Kretschmer wrote:
Use timeofday() instead, now() returns the transaction starting time.
timeofday() is a legacy function kept only for backwards-compatibility.
It returns a string, which is quite awkward. Use clock_timestamp() instead.
--
Heikki Linnakangas
Hi,
Sorry, if posting here was not proper instead of starting new thread
(I am really not sure if its bad thing to do)
I would like to share my recent experience on implementation of
client side pooling using pgbouncer. By client side i mean that
the the pgbouncer process in not on same machine
note: my postgresql server pgbouncer were not in virtualised environment
in the first setup. Only application server has many openvz containers.
Nice suggestion to try ,
I will put pgbouncer on raw hardware and run pgbench from same hardware.
regds
rajesh kumar mallah.
Why in VM (openvz container) ?
Did you also try it in the same OS as your appserver ?
Perhaps even connecting from appserver via unix seckets ?
and all my
Rajesh Kumar Mallah wrote:
the no of clients was 10 ( -c 10) carrying out 1 transactions
each (-t 1) .
pgbench db was initilised with scaling factor -s 100.
since client count was less there was no queuing of requests in pgbouncer
i would prefer to say it was in 'passthrough' mode.
ok ,
now the question is , is it possible to dig out from from postgresql
database
server if connection pooling is needed ? In our case eg i have kept
max_connections = 300 if i reduce below 250 i get error max connection
reached.
on connecting to db directly, if i put pgbouncer i get less
On Sun, Jul 18, 2010 at 10:55 PM, Greg Smith g...@2ndquadrant.com wrote:
Rajesh Kumar Mallah wrote:
the no of clients was 10 ( -c 10) carrying out 1 transactions each
(-t 1) .
pgbench db was initilised with scaling factor -s 100.
since client count was less there was no queuing
On Jul 9, 2010, at 8:33 PM, Craig Ringer wrote:
On 10/07/2010 9:25 AM, Josh Berkus wrote:
It *is* the last place you want to put it, but putting it there can
be much better than not putting it *anywhere*, which is what we've
often seen.
Well, what you proposed is an admission control
Looks like ,
pgbench cannot be used for testing with pgbouncer if number of
pgbench clients exceeds pool_size + reserve_pool_size of pgbouncer.
pgbench keeps waiting doing nothing. I am using pgbench of postgresql 8.1.
Are there changes to pgbench in this aspect ?
regds
Rajesh Kumar Mallah.
On
On Sun, 2010-07-18 at 21:48 +0530, Rajesh Kumar Mallah wrote:
Hi,
Sorry, if posting here was not proper instead of starting new thread
(I am really not sure if its bad thing to do)
I would like to share my recent experience on implementation of
client side pooling using pgbouncer. By
Thanks for the thought but it (-C) does not work .
BTW, I think you should use -C option with pgbench for this kind of
testing. -C establishes connection for each transaction, which is
pretty much similar to the real world application which do not use
connection pooling. You will be
From: Rajesh Kumar Mallah mallah.raj...@gmail.com
Subject: Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.
Date: Mon, 19 Jul 2010 08:06:09 +0530
Message-ID: aanlktilggkbmc9h7wlhlcdqfm5rjth1-9dpf8golv...@mail.gmail.com
Thanks for the thought but it (-C) does not work .
Still
12 matches
Mail list logo
