Firstly, 50,000 visitors isn't really a whole lot. But the number of simos is what's really important. Do they show up, do one or two things, then leave, or do they spend the whole day on the site? I'll assume something in between.
It is better to just connect and stay connected. Connections cost a fair bit of time, so disconnecting and reconnecting can be a majority of the time your script spends processing.
DO NOT USE pg_pconnect unless you know EXACTLY what you are doing. Apache's multi-process design and PHP gang up to open a database connection for each and every child process, and wind up spawning a WHOLE bunch of those child processes, usually up the max number of child processes you have apache set for. The default for apache is 150, but can be much higher on a busy site, like the one you are describing.
Since each apache child spawns a connection, that means there is one postgresql backend running for each apache child running, and this can chew up memory VERY fast, resulting in a very slow database.
pg_connect runs at a rate of about 1/1,000 of second on my web server (dual PIII 750MHz with 512 Megt ram) while pg_pconnect runs something like 1/1,000,000 of a second.
Meanwhile, having 200 postgresql backends up and running can chew up so much base memory (about 1 Meg per backend is unshared memory) that on my 512Meg machine the query response teim can go from ~100 ms for most queries to >1000 ms quickly.
The short answer: Don't disconnect/reconnect to the database, and DO NOT USE pg_pconnect without a LOT more memory than you have, and you better test your configuration under heavy load to be sure you have it set up right or people will start getting "too many backend connections to database server" errors at the peak time, the worst time for the server to start slowing down and misbehaving.
