On Wed, Apr 18, 2001 at 05:37:27PM +0200, Frank Joerdens allegedly wrote:
> I think the real issue with PHP/PostgreSQL and persistent connections
> was to do with transactions. AFAIK the too-many-connections issue was
> easy to fix through some fiddling with appropriaty parameters
> (max_connections or something, I forget) in php.ini - it's not too well
> documented, you'd best just play with it and try some different options
> (I don't have the problem, I _am_ using persistent connections, and I
> can send you what I put in my php.ini if you want).
I've seen both MySQL and PostgreSQL give up (MySQL just hung, pgsql
cored) when I tried simple selects from a couple of hundred concurrent
connections; no transactions or other fancy stuff there. I think I was
using MySQL 3.22.?? and pgsql 6.5.3, so more modern versions may well be
able to cope with these numbers of connections. It's been more than a
year since I last tried it.
> AFAIK the problem is somehow rooted in the fact that PHP folks up until
> very recently used to have a strong MySQL bias, which doesn't (or
> didn't, until very recently) have proper transaction support. Hence they
> didn't really consider this scenario.
I don't know what the current state of affairs is, but it is my
understanding that, while pgsql performs admirably on tasks which mostly
read data, pgsql isn't really able to cope (performance wise) with an
application that has a very high insert to select ratio, such as OLTP.
I'm looking into using pgsql to for implementing datamarts for a CRM
application, so I'll so how that goes in the next couple of weeks. I'm
keeping my fingers crossed ;)
The reason for the previous paragraph is that I think pgsql (PHP even
more so) is mosty used for databases in which the insert to select ratio
is much more favourable. But hey, that's my opinion.
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum