Re: Re: [GENERAL] PostgreSQL vs. MySQL

This "pre-starting" is already being done by any web application that uses
connection pooling. (I suspect this speed of connection startup is only
important for something like a web system, correct?). Even if you did
"pre-start" these back-ends, you'd end up with one of two possibilities:

- you reuse the back-end processes from one connection to the other. I
suspect this is very hard, and you'd just be recreating connection pooling
at a lower level, which I don't think is that worthwhile an investment...

- you don't reuse the back-end processes, in which case you're still
spawning one process per connection, which remains a bad idea for web
systems, so you're back to the application-layer connection pooling idea.

I admire the entire Postgres's team efforts to fix any and all issues that
come in. You guys show true humility and a real desire to make this product
the best it can be.

It seems to me, though, that this particular issue is better resolved at the
application layer.

-Ben

on 7/10/00 1:02 AM, Tom Lane at tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:

>> You could pre-start servers (ala Apache), then when a connection request
>> comes in, the connection should be pretty fast. This would involve
>> defining, for each database, the number of servers to prestart (default 0),
>
> Yeah, that's been discussed before. It seems possible if not exactly
> simple --- one of the implications is that the postmaster no longer
> listens for client connections, but is reduced to being a factory for
> new backends. The prestarted backends themselves have to be listening
> for client connections, since there's no portable way for the postmaster
> to pass off a client socket to an already-existing backend.
>
> And of course the major problem with *that* is how do you get the
> connection request to arrive at a backend that's been prestarted in
> the right database? If you don't commit to a database then there's
> not a whole lot of prestarting that can be done.
>
> It occurs to me that this'd get a whole lot more feasible if one
> postmaster == one database, which is something we *could* do if we
> implemented schemas. Hiroshi's been arguing that the current hard
> separation between databases in an installation should be done away
> with in favor of schemas, and I'm starting to see his point...
>
> regards, tom lane
>