Skip site navigation (1) Skip section navigation (2)

Re: profiling connection overhead

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: profiling connection overhead
Date: 2010-12-01 14:24:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wednesday 01 December 2010 15:20:32 Robert Haas wrote:
> On Tue, Nov 30, 2010 at 11:32 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > On 11/28/10, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> To some degree we're a
> >> victim of our own flexible and extensible architecture here, but I
> >> find it pretty unsatisfying to just say, OK, well, we're slow.
> > 
> > What about "well OK, we have PGbouncer"?  Are there fixable
> > short-comings that it has which could make the issue less of an issue?
> We do have pgbouncer, and pgpool-II, and that's a good thing.  But it
> also requires proxying every interaction with the database through an
> intermediate piece of software, which is not free.  An in-core
> solution ought to be able to arrange for each new connection to be
> directly attached to an existing backend, using file-descriptor
> passing.  Tom has previously complained that this isn't portable, but
> a little research suggests that it is supported on at least Linux, Mac
> OS X, FreeBSD, OpenBSD, Solaris, and Windows, so in practice the
> percentage of our user base who could benefit seems like it would
> likely be very high.
HPUX and AIX allow fd transfer as well. I still don't see what even remotely 
relevant platform would be a problem.


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-12-01 14:27:21
Subject: Re: FK's to refer to rows in inheritance child
Previous:From: Robert HaasDate: 2010-12-01 14:20:32
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group