On Wed, 2010-07-14 at 08:58 -0500, Kevin Grittner wrote:
> Scott Marlowe wrote:
> > Hannu Krosing wrote:
> >> One example where you need a separate connection pool is pooling
> >> really large number of connections, which you may want to do on
> >> another host than the database itself is running
Scott Marlowe wrote:
> Hannu Krosing wrote:
>> One example where you need a separate connection pool is pooling
>> really large number of connections, which you may want to do on
>> another host than the database itself is running.
>
> Definitely. Often it's best placed on the individual webser
On Thu, Jul 8, 2010 at 11:48 PM, Hannu Krosing wrote:
> One example where you need a separate connection pool is pooling really
> large number of connections, which you may want to do on another host
> than the database itself is running.
Definitely. Often it's best placed on the individual webs
On Fri, 2010-07-09 at 00:42 -0400, Tom Lane wrote:
> Samuel Gendler writes:
> > On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
> > wrote:
> >> If you're not using a connection pool, start using one.
>
> > I see this issue and subsequent advice cross this list awfully
> > frequently. Is there in a
Craig Ringer wrote:
> It'll need to separate "running queries" from "running processes", or
> start threading backends, so that one way or the other a single query
> can benefit from the capabilities of multiple CPUs. The same separation,
> or a move to async I/O, might be needed to get one query t
Two problems to recognize. First is that building something in has the
potential to significantly limit use and therefore advancement of work
on external pools, because of the "let's use the built in one instead of
installing something extra" mentality. I'd rather have a great external
Jesper Krogh wrote:
I dont think a build-in connection-poller (or similiar) would in any
way limit the actions and abillities of an external one?
Two problems to recognize. First is that building something in has the
potential to significantly limit use and therefore advancement of work
on e
On 2010-07-10 00:59, Greg Smith wrote:
Matthew Wakeling wrote:
> If you have an external pool solution, you can put it somewhere
> else - maybe on multiple somewhere elses.
This is the key point to observe: if you're at the point where you
have so many connections that you need a pool, the l
On 10/07/10 00:56, Brad Nicholson wrote:
On Fri, 2010-07-09 at 00:42 -0400, Tom Lane wrote:
Perhaps not, but there's no obvious benefit either. Since there's
More Than One Way To Do It, it seems more practical to keep that as a
separate problem that can be solved by a choice of add-on pack
Greg Smith wrote:
> if you're at the point where you have so many connections that you
> need a pool, the last place you want to put that is on the
> overloaded database server itself. Therefore, it must be an
> external piece of software to be effective, rather than being part
> of the server
Matthew Wakeling wrote:
If you have an external pool solution, you can put it somewhere else -
maybe on multiple somewhere elses.
This is the key point to observe: if you're at the point where you have
so many connections that you need a pool, the last place you want to put
that is on the ov
On Fri, Jul 9, 2010 at 12:42 AM, Tom Lane wrote:
> Samuel Gendler writes:
>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
>> wrote:
>>> If you're not using a connection pool, start using one.
>
>> I see this issue and subsequent advice cross this list awfully
>> frequently. Is there in architec
"Jorge Montero" wrote:
> If anything was built in the database to handle such connections,
> I'd recommend a big, bold warning, recommending the use of client-
> side pooling if available.
+1
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make chang
If anything was built in the database to handle such connections, I'd recommend
a big, bold warning, recommending the use of client-side pooling if available.
For something like, say, a web-server, pooling connections to the database
provides a massive performance advantage regardless of how goo
Matthew Wakeling wrote:
> On Fri, 9 Jul 2010, Kevin Grittner wrote:
>>> Interesting idea. As far as I can see, you are suggesting
>>> solving the too many connections problem by allowing lots of
>>> connections, but only allowing a certain number to do anything
>>> at a time?
>>
>> Right.
>
> I t
On Fri, 9 Jul 2010, Kevin Grittner wrote:
Interesting idea. As far as I can see, you are suggesting solving
the too many connections problem by allowing lots of connections,
but only allowing a certain number to do anything at a time?
Right.
I think in some situations, this arrangement would
If your app is running under Tomcat, connection pooling is extremely easy to
set up from there: It has connection pooling mechanisms built in. Request your
db connections using said mechanisms, instead of doing it manually, make a
couple of changes to server.xml, and the problem goes away. Hundr
In case there's any doubt, the questions below aren't rhetorical.
Matthew Wakeling wrote:
> Interesting idea. As far as I can see, you are suggesting solving
> the too many connections problem by allowing lots of connections,
> but only allowing a certain number to do anything at a time?
Rig
On Fri, 9 Jul 2010, Kevin Grittner wrote:
Any thoughts on the "minimalist" solution I suggested a couple weeks
ago?:
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01385.php
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01387.php
So far, there has been no comment by anyone...
Brad Nicholson wrote:
> Just like replication, pooling has different approaches. I do
> think that in both cases, having a solution that works, easily,
> out of the "box" will meet the needs of most users.
Any thoughts on the "minimalist" solution I suggested a couple weeks
ago?:
http://arc
Thanx you all for the replies.
I got a gist on where should I head towards
like I should rely a bit on postgres for performance and rest on my
tomcat and application.
And will try connection pooling on postgres part.
And if I come back for any query (related to this topic) then this
time it will b
On Fri, 2010-07-09 at 00:42 -0400, Tom Lane wrote:
> Samuel Gendler writes:
> > On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
> > wrote:
> >> If you're not using a connection pool, start using one.
>
> > I see this issue and subsequent advice cross this list awfully
> > frequently. Is there in a
Otherwise I'm wondering if PostgreSQL will begin really suffering in
performance on workloads where queries are big and expensive but there
are relatively few of them running at a time.
Oh, I should note at this point that I'm *not* whining that "someone"
should volunteer to do this, or that "t
Thanx you all for the replies.
I got a gist on where should I head towards
like I should rely a bit on postgres for performance and rest on my
tomcat and application.
And will try connection pooling on postgres part.
And if I come back for any query (related to this topic) then this
time it will b
On 09/07/10 12:42, Tom Lane wrote:
> Samuel Gendler writes:
>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
>> wrote:
>>> If you're not using a connection pool, start using one.
>
>> I see this issue and subsequent advice cross this list awfully
>> frequently. Is there in architectural reason w
Samuel Gendler writes:
> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
> wrote:
>> If you're not using a connection pool, start using one.
> I see this issue and subsequent advice cross this list awfully
> frequently. Is there in architectural reason why postgres itself
> cannot pool incoming co
On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
wrote:
> If you're not using a connection pool, start using one.
>
> Do you really need 100 *active* working query threads at one time? Because
> if you do, you're going to need a scary-big disk subsystem and a lot of
> processors.
I see this issue and
On 9/07/2010 3:20 AM, Harpreet singh Wadhwa wrote:
Hi,
I want to fine tune my postgresql to increase number of connects it
can handle in a minutes time.
Decrease the response time per request etc.
The exact case will be to handle around 100 concurrent requests.
If you're not using a connectio
Harpreet singh Wadhwa wrote:
> I want to fine tune my postgresql to increase number of connects
> it can handle in a minutes time.
> Decrease the response time per request etc.
> The exact case will be to handle around 100 concurrent requests.
I have found that connection pooling is crucial.
Hi,
I want to fine tune my postgresql to increase number of connects it
can handle in a minutes time.
Decrease the response time per request etc.
The exact case will be to handle around 100 concurrent requests.
Can any one please help me in this.
Any hardware suggestions are also welcomed.
Reg
30 matches
Mail list logo
