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

Re: [INTERFACES] Re: PHP and PostgreSQL

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Karl DeBisschop <karl(at)debisschop(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL-interfaces <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: [INTERFACES] Re: PHP and PostgreSQL
Date: 2001-01-02 07:16:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
Does this requested chagne have to do with Apache or PostgreSQL?

w wrote:
> > 
> >         I have been asked by the major PHP developer Rasmus Lerdorf to see
> > if
> >         the PostgreSQL/PHP interface needs any improvements.
> > 
> >         Is the current PostgreSQL interface module in PHP adequate?  Does it
> >         support all the current libpq features?
> > 
> > The only problem we have run into (and I have heard of others having this
> > problem also) is with persistent connections.  I have seen discussion on
> > persistent connection problems but I'm not sure the problem was ever
> > resolved.  The problem we have seen is that when using persistent
> > connections the web server doesn't seen to reuse the connections or somthing
> > to that effect.  The result being that we eventually use up our postgres
> > limit of 48 connections and nothing can connect to postgre anymore.  It is
> > possible that this is a configuration problem that we haven't sufficiently
> > investigated, but I meniton it because I have heard other talk of this.
> > Anyone have more information?
> Persistent connections behave exactly as advertised. Each apache process
> sets up and maintains persistent connections as needed. The problem is
> that for a typical web server, there are so many subprocesses that
> persistent connections are probably consume more resources than they
> save, unless they are combined with connection pooling across ALL the
> apache processes.
> Implementation of connection pooling is by far the most serious
> shortcoming of the current implementation, IMHO. 
> I would dearly love to see this addressed as our postgresql database
> sees connections from about 300 servers for 6 databases. Since our
> postgresql server cannot support 1800 simultaneous active backends,
> persistent connections are useless without pooling. So instead we
> initiate 10 or more backends every second for generally very simple
> queries. Most of the queries are pretty simple, so I would not be at all
> surprised if we sent more system resources opening connections than we
> do actually answering queries
> -- 
> Karl DeBisschop                      kdebisschop(at)alert(dot)infoplease(dot)com
> Learning Network/Information Please
> Netsaint Plugin Developer            kdebisschop(at)users(dot)sourceforge(dot)net

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-01-02 07:30:07
Subject: Re: [patch] src/include/storage/s_lock.h
Previous:From: Thomas LockhartDate: 2001-01-02 07:11:52
Subject: Re: [HACKERS] Re: Inheritance docs error.

pgsql-interfaces by date

Next:From: Bruce MomjianDate: 2001-01-02 07:44:58
Subject: Re: wrong values in ODBC parameters?
Previous:From: Tom LaneDate: 2001-01-02 04:59:56
Subject: Re: PHP and PostgreSQL

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