ummmm. Not exactly. When you use pconnect, the connection is held open after processing a php page, and reused for the next php file that calls pconnect with the same connection string (more or less, there are differences for MySQL versus PostgreSQL versus other databases...)
mysql_close (or any other db's close() function for that matter) does not close a pconnect opened connection, and is ignored.
Generally, pconnects are a solution in search of a problem, and are known to cause problems with using up too many connections. If you don't have a performance problem with regular conects, there's little reason to investigate pconnects. If you are having a performance problem, be aware that pconnects may or may not be a solution for you, and they require that you properly configure your web server and database so that the web server doesn't accidentally use up all your connections under heavy load.
Let's say that your PHP app connects to two different databases to get the job done. If you have apache (I'm assuming you're using apache) set for 150 maximum children, then you could theoretically have 300 database connections open at one time under load.
This is generally a bad thing, as that's far too many connections. By lowering the maximum number of apache children you can keep the database from being overloaded, but if you have hundreds of users the apache children are now serving them round robin, with no keep alive, and the performance hit from that may or may not negate any gains from persistant connections.
For most PHP scripts the cost of connecting to the database appears as noise against the far greater cost of running the script.
