introduce bugs. If we can get to the point where we have something to
play around with, even if it's kind of kludgey or doesn't quite work,
it'll give us some idea of whether further effort is worthwhile and
how it should be directed.
Should I put this on the TODO list, then, in hopes that s
On Wed, Jul 28, 2010 at 4:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> However, if we don't support that, we can't do any sort of pooling-ish
>> thing without the ability to pass file descriptors between processes;
>> and Tom seems fairly convinced there's no portable way to do that.
>
> Well,
On Wed, Jul 28, 2010 at 04:10:08PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > However, if we don't support that, we can't do any sort of pooling-ish
> > thing without the ability to pass file descriptors between processes;
> > and Tom seems fairly convinced there's no portable way to do that
Robert Haas writes:
> However, if we don't support that, we can't do any sort of pooling-ish
> thing without the ability to pass file descriptors between processes;
> and Tom seems fairly convinced there's no portable way to do that.
Well, what it would come down to is: are we prepared to not sup
On Wed, Jul 28, 2010 at 3:44 PM, Josh Berkus wrote:
> On 7/27/10 6:56 PM, Tom Lane wrote:
>> Yeah, if it weren't for that I'd say "sure let's try it". But I'm
>> afraid we'd be introducing significant headaches in return for a gain
>> that's quite speculative.
>
> Well, the *gain* isn't speculati
On 7/27/10 6:56 PM, Tom Lane wrote:
> Yeah, if it weren't for that I'd say "sure let's try it". But I'm
> afraid we'd be introducing significant headaches in return for a gain
> that's quite speculative.
Well, the *gain* isn't speculative. For example, I am once again
dealing with the issue that
28.07.10 04:56, Tom Lane написав(ла):
I'm not asserting it's true, just suggesting it's entirely possible.
Other than the fork() cost itself and whatever authentication activity
there might be, practically all the startup cost of a new backend can be
seen as cache-populating activities. You'd h
On 28/07/10 04:40, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 22, 2010 at 5:29 PM, Andres Freund wrote:
The problem is harder for us because a backend can't switch identities
once it's been assigned to a database. I haven't heard an adequate
explanation of why that could
Robert Haas writes:
> On Tue, Jul 27, 2010 at 9:56 PM, Tom Lane wrote:
>> Other than the fork() cost itself and whatever authentication activity
>> there might be, practically all the startup cost of a new backend can be
>> seen as cache-populating activities. You'd have to redo all of that,
>>
On Tue, Jul 27, 2010 at 9:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 27, 2010 at 4:40 PM, Tom Lane wrote:
>>> "Flushing them all" is not zero-cost; it's not too hard to believe that
>>> it could actually be slower than forking a clean new backend.
>
>> I'm not so sure I believe
Robert Haas writes:
> On Tue, Jul 27, 2010 at 4:40 PM, Tom Lane wrote:
>> "Flushing them all" is not zero-cost; it's not too hard to believe that
>> it could actually be slower than forking a clean new backend.
> I'm not so sure I believe that.
I'm not asserting it's true, just suggesting it's
On Tue, Jul 27, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 22, 2010 at 5:29 PM, Andres Freund wrote:
The problem is harder for us because a backend can't switch identities
once it's been assigned to a database. I haven't heard an adequate
explanation of
Robert Haas writes:
> On Thu, Jul 22, 2010 at 5:29 PM, Andres Freund wrote:
>>> The problem is harder for us because a backend can't switch identities
>>> once it's been assigned to a database. I haven't heard an adequate
>>> explanation of why that couldn't be changed, though.
>> Possibly it m
On Sat, Jul 24, 2010 at 2:23 AM, Craig Ringer
wrote:
> On 24/07/10 01:28, Robert Haas wrote:
>
>> Well, if we could change the backends so that they could fully
>> reinitialize themselves (disconnect from a database to which they are
>> bound, etc.), I don't see why we couldn't use the Apache appr
On Sat, 2010-07-24 at 14:36 +0800, Craig Ringer wrote:
> On 24/07/10 13:23, Greg Smith wrote:
> > Joshua Tolley wrote:
> >> Relatively minor, but it would be convenient to avoid having to query
> >> $external_pooler to determine the client_addr of an incoming connection.
> >>
> >
> > You sugges
On Fri, 2010-07-23 at 09:52 -0700, Joshua D. Drake wrote:
> On Thu, 2010-07-22 at 20:56 +0100, Hannu Krosing wrote:
> >
> > > Let's extend this shall we:
> > >
> > > Avoid adding yet another network hop
> >
> > postgreSQL is multi-process, so you either have a separate "pooler
> > process" or n
Craig Ringer writes:
> 9.0 has application_name to let apps identify themselves. Perhaps a
> "pooled_client_ip", to be set by a pooler rather than the app, could be
> added to address this problem in a way that can be used by all poolers
> new and existing, not just any new in-core pooling system.
On 24/07/10 13:23, Greg Smith wrote:
> Joshua Tolley wrote:
>> Relatively minor, but it would be convenient to avoid having to query
>> $external_pooler to determine the client_addr of an incoming connection.
>>
>
> You suggest this as a minor concern, but I consider it to be one of the
> most
On 24/07/10 01:28, Robert Haas wrote:
> Well, if we could change the backends so that they could fully
> reinitialize themselves (disconnect from a database to which they are
> bound, etc.), I don't see why we couldn't use the Apache approach.
This would offer the bonus on the side that it'd be m
On Sat, Jul 24, 2010 at 01:23:08AM -0400, Greg Smith wrote:
> Joshua Tolley wrote:
> >Relatively minor, but it would be convenient to avoid having to query
> >$external_pooler to determine the client_addr of an incoming connection.
>
> You suggest this as a minor concern, but I consider it to be on
Joshua Tolley wrote:
Relatively minor, but it would be convenient to avoid having to query
$external_pooler to determine the client_addr of an incoming connection.
You suggest this as a minor concern, but I consider it to be one of the
most compelling arguments in favor of in-core pooling.
On Fri, Jul 23, 2010 at 01:28:53PM -0400, Robert Haas wrote:
> On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing wrote:
> > On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
> >> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
> >> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
>
On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> >> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> >> wrote:
> >> > So rather than asking "should core have a connection pool"
On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing wrote:
> On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
>> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
>> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
>> >> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
>> >> wrote:
>> >
On Thu, 2010-07-22 at 20:56 +0100, Hannu Krosing wrote:
>
> > Let's extend this shall we:
> >
> > Avoid adding yet another network hop
>
> postgreSQL is multi-process, so you either have a separate "pooler
> process" or need to put pooler functionality in postmaster, bothw ways
> you still have
On Thu, Jul 22, 2010 at 02:44:04PM -0700, Scott Carey wrote:
> On Jul 22, 2010, at 11:36 AM, Robert Haas wrote:
> > On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> > wrote:
> >> So rather than asking "should core have a connection pool" perhaps
> >> what's needed is to ask "what can an in-core poo
On Thu, Jul 22, 2010 at 5:29 PM, Andres Freund wrote:
>> The problem is harder for us because a backend can't switch identities
>> once it's been assigned to a database. I haven't heard an adequate
>> explanation of why that couldn't be changed, though.
> Possibly it might decrease the performanc
On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing wrote:
> On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
>> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
>> wrote:
>> > So rather than asking "should core have a connection pool" perhaps
>> > what's needed is to ask "what can an in-core pool d
On Jul 22, 2010, at 11:36 AM, Robert Haas wrote:
> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> wrote:
>> So rather than asking "should core have a connection pool" perhaps
>> what's needed is to ask "what can an in-core pool do that an external
>> pool cannot do?"
>
> Avoid sending every co
On Thu, 2010-07-22 at 12:15 -0700, Joshua D. Drake wrote:
> On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> > On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> > wrote:
> > > So rather than asking "should core have a connection pool" perhaps
> > > what's needed is to ask "what can an in-cor
On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> wrote:
> > So rather than asking "should core have a connection pool" perhaps
> > what's needed is to ask "what can an in-core pool do that an external
> > pool cannot do?"
>
> Avoid sending ev
On Thu, Jul 22, 2010 at 02:33:43PM -0400, Robert Haas wrote:
> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> wrote:
> > On 12/07/10 17:45, Matthew Wakeling wrote:
> >>
> >> I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
> >> load of non-portable stuff? It seems to work o
On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> wrote:
> > So rather than asking "should core have a connection pool" perhaps
> > what's needed is to ask "what can an in-core pool do that an external
> > pool cannot do?"
>
> Avoid sending e
On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
wrote:
> So rather than asking "should core have a connection pool" perhaps
> what's needed is to ask "what can an in-core pool do that an external
> pool cannot do?"
Avoid sending every connection through an extra hop.
--
Robert Haas
EnterpriseDB:
On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
wrote:
> On 12/07/10 17:45, Matthew Wakeling wrote:
>>
>> I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
>> load of non-portable stuff? It seems to work on a whole load of platforms.
>
> A lot of what Apache HTTPd does is handl
From: Rajesh Kumar Mallah
Subject: Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.
Date: Mon, 19 Jul 2010 08:06:09 +0530
Message-ID:
> Thanks for the thought but it (-C) does not work .
Still you need:
pgbench's -c <= (pool_size + reserve_pool_size)
--
Tatsu
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 s
> 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 ?
Pgbench won't start actual transactio
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
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 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 admis
On Sun, Jul 18, 2010 at 10:55 PM, Greg Smith 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 of request
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
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.
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
note: my postgresql server & pgbouncer were not in virtualised environment
in the first setup. Only application server has many openvz containers.
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
On Tue, Jul 13, 2010 at 16:42, Dimitri Fontaine wrote:
> Tom Lane writes:
>> I agree with the comments to the effect that this is really a packaging
>> and documentation problem. There is no need for us to re-invent the
>> existing solutions, but there is a need for making sure that they are
>>
Tom Lane writes:
> I agree with the comments to the effect that this is really a packaging
> and documentation problem. There is no need for us to re-invent the
> existing solutions, but there is a need for making sure that they are
> readily available and people know when to use them.
On this t
On Mon, 2010-07-12 at 18:58 +0800, Craig Ringer wrote:
> On 12/07/10 17:45, Matthew Wakeling wrote:
> >
> > I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
> > load of non-portable stuff? It seems to work on a whole load of platforms.
>
> A lot of what Apache HTTPd does is
Craig Ringer wrote:
> So rather than asking "should core have a connection pool" perhaps
> what's needed is to ask "what can an in-core pool do that an
> external pool cannot do?"
(1) It can prevent the most pessimal performance problems resulting
from lack of an external connection pool (or
On 12/07/10 17:45, Matthew Wakeling wrote:
>
> I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
> load of non-portable stuff? It seems to work on a whole load of platforms.
A lot of what Apache HTTPd does is handled via the Apache Portable
Runtime (APR). It contains a lot o
On Sat, 10 Jul 2010, Tom Lane wrote:
Doesn't pgpool do this?
No, and in fact that's exactly why the proposed implementation isn't
ever going to be in core: it's not possible to do it portably.
I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
load of non-portable stuff?
Josh Berkus writes:
>> I'm also relying on the unsubstantiated assumption that it's
>> possible to pass a socket connection between processes.
> Doesn't pgpool do this?
No, and in fact that's exactly why the proposed implementation isn't
ever going to be in core: it's not possible to do it porta
Right, let's not confuse Kevin's argument that we should have
connection pooling in core with advocacy for any particular patch or
feature suggestion that he may have offered on some other thread. A
very simple in-core connection pooler might look something like this:
when a session terminates,
Sent from my iPhone
On Jul 9, 2010, at 18:25, Josh Berkus wrote:
So while adding (b) to core alone would be very useful for some users,
ironically it's generally for the more advanced users which are not
the
ones we're trying to help on this thread.
It would seem from evidence presente
On Fri, Jul 9, 2010 at 11: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 adm
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 mechanism, which is
*different* from a connection pool,
> 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 mechanism, which is
*different* from a connection pool, although the two overlap. A
connection
59 matches
Mail list logo
