Persistent Connections

Persistent connections are SQL links that do not close when the execution of your script ends.
When a persistent connection is requested, PHP checks if there's already an identical persistent connection (that remained open from earlier).

Persistent connections are efficient if the overhead to create a link to your SQL server is high, for example because the web server does not run on the same computer as the database server.

Persistent connections do not give you any functionality that is not possible with non-persistent connections.
They were designed to have one-to-one mapping to regular connections. You should always be able to replace persistent connections with non-persistent connections.

resource pg_pconnect ( string connection_string):
Opens a persistent connection, and returns a connection resource like pg_connect() that is needed by other PostgreSQL functions.
The connection_string parameter is the same as for pg_connect().
pg_close() will not close persistent links generated by pg_pconnect().

Background on Web Servers, their Children and DB Connections

There are three ways in which your web server can utilize PHP to generate web pages.

The first method is to use PHP as a CGI "wrapper". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections -- they simply don't persist.

The second, and most popular, method is to run PHP as a module in a multiprocess web server, which currently only includes Apache.
A multiprocess server typically has one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When each request comes in from a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be serviced by a different child process than the first time. What a persistent connection does for you in this case it make it so each child process only needs to connect to your SQL server the first time that it serves a page that makes use of such a connection. When another page requires a connection to the SQL server, it can reuse the connection that child established earlier.

Why Using Persistent Connections?

The answer here is extremely simple -- efficiency. Persistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably.

Drawbacks of Persistent Connections

If you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Check your database documentation for information on handling abandoned or idle connections.

There are a couple of additional caveats to keep in mind when using persistent connections. One is that when using table locking on a persistent connection, if the script for whatever reason cannot release the lock, then subsequent scripts using the same connection will block indefinitely and may require that you either restart the httpd server or the database server.
Another is that when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does. In either case, you can use register_shutdown_function() to register a simple cleanup function to unlock your tables or roll back your transactions. Better yet, avoid the problem entirely by not using persistent connections in scripts which use table locks or transactions (you can still use them elsewhere).

php.ini Configuration

To enable persistent connection, the pgsql.allow_persistent php.ini directive must be set to "On" (which is the default).

The maximum number of persistent connection can be defined with the pgsql.max_persistent php.ini directive (defaults to -1 for no limit).