Re: pg_pconnect - ??

On Sat, Feb 02, 2002 at 12:35:56PM -0500, Chadwick Rolfs wrote:
> On Sat, 2 Feb 2002, Frank Joerdens wrote:
[ . . . ]
> > PII 400). It makes quite a difference, speed-wise, which would support
> > my line of reasoning. I didn't try to measure this scientifically (or
> > pseudo-scientifically, for that matter).
>
> It's hard for me to tell here whether you are referring to
> faster connections, or slower connections. I know the query run time is
> important in this discussion, so I assume the two latter statments above
> are regarding connection time.

I seem to be having difficulties expressing myself clearly these days
(others have complained) ;-/. All I was trying to say is that, very
subjectively, the web pages served from Postgres where appearing quicker
after splitting webserver and database server onto 2 distinct machines.
I realize this doesn't mean anything. Could be my imagination and/or
wishful thinking.

> Frank: are you using pconnect?

Yes.

> If so: are you using it due to slower
> connection times through your tcp/ip (?is what you're using, right?)
> sockets?

No, just because they are generally faster with simple queries. And
because I can afford it (I'm not bothered by all those idle postgres
children hanging about in memory).

> -and- are you able to use unix sockets with solaris?

That was a while ago when I tried, and no, I didn't get it work, and
used TCP/IP on that server at the client's site (not the server I am
using here) instead.

> Does the
> added physical layer make tcp/ip much slower, slower, or not at all?

Impossible to say from my unsystematic experimentation because the new
machine is at least twice as fast as the webserver box. For this reason
alone I expected everything to be faster (I basically split the work
between 4 processors, 2 on each box, and 2 SCSI controllers, one on each
box), and so it was. This may count as circumstantial evidence at the
very most, I know.

> Point me to the thread, please.

http://archives.postgresql.org/pgsql-general/2001-01/msg01427.php

> Personally, I see pconnects being used on the web/postgres/php server
> here, and there are always about 10 children lying arond idle. There is
> no connection time difference between pconnect and connect.

I doubt it (can anyone come up with an ingeniously simple,
straightforward, and counclusive experimental set-up to allow us to talk
about this a little more scientifically?).

> I see no need
> to use them. When the database server does eventually move to it's own
> box (maybe), I'm wondering if I should recommend persistence if connection
> is slow... as well as a shorter connection timeout.
>
> I'm also wondering if I should offer to change all those pconnect
> statements to connect to save on resources that the idle children take
> up.. ;P

At one of our client's sites, their sysadmin was bothered too about
those idle processes hanging about . . . so I removed pconnect. It still
works OK, basically because the machine in question is ludicrously
overpowered for the app.

Regards, Frank