How hard would it be to pre-fork an extra backend for the database a
user just requested so if they next user asks for the same database, the
backend would already be started?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
At 04:50 PM 9/29/01 -0400, Tom Lane wrote:
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> On some operating systems, only one child at a time can accept() on the
>>> socket. On these, you have to lock around the call to accept().
>
>> But how do you know the client wants the database you have for
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > How hard would it be to pre-fork an extra backend
>
> How are you going to pass the connection socket to an already-forked
> child process? AFAIK there's no remotely portable way ...
Umm... Apache? They use a preforking model and it works quite w
On Sat, 29 Sep 2001 [EMAIL PROTECTED] wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > How hard would it be to pre-fork an extra backend
> >
> > How are you going to pass the connection socket to an already-forked
> > child process? AFAIK there's no remotely portable way ...
>
> Umm.
Gavin Sherry <[EMAIL PROTECTED]> writes:
> This aside, isn't it possible to just copy the socket and some
> data about the database required into shared memory and have the preforked
> children pick the socket up from there.
Ummm No. There's no Unix API for doing so.
You can pass open fil
* Gavin Sherry ([EMAIL PROTECTED]) [010930 06:13]:
> On Sat, 29 Sep 2001 [EMAIL PROTECTED] wrote:
>
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > How hard would it be to pre-fork an extra backend
> > >
> > > How are you going to pass the connection socket to an already-forked
> > > chi
Doug McNaught wrote:
>
> You can pass open file descriptors across Unix domain sockets on most
> systems, which is a possible way to address the problem, but probably
> not worth it for the reasons discussed earlier.
I think that it does solve the problem. The only drawback is that it's not
port
Bradley McLean <[EMAIL PROTECTED]> writes:
> Is it useful if it only works for one database within a server?
Once we have schemas (7.3, I hope), I think a lot of installations will
have only one production database. However, if we were going to do this
what we'd probably do is allow the DBA to c
>
> Once we have schemas (7.3, I hope), I think a lot of installations will
> have only one production database. However, if we were going to do this
> what we'd probably do is allow the DBA to configure the postmaster to
> start N pre-forked backends per database, where N can depend on the
> d
> >
> > How hard would it be to pre-fork an extra backend for the database a
> > user just requested so if they next user asks for the same database, the
> > backend would already be started?
Perhaps I'm missing something, but it seems to me that the cost of forking
a new backend would be prett
> > >
> > > How hard would it be to pre-fork an extra backend for the database a
> > > user just requested so if they next user asks for the same database, the
> > > backend would already be started?
>
> Perhaps I'm missing something, but it seems to me that the cost of forking
> a new backend
At 08:16 PM 30-09-2001 -0600, Steve Wolfe wrote:
>> >
>> > How hard would it be to pre-fork an extra backend for the database a
>> > user just requested so if they next user asks for the same database, the
>> > backend would already be started?
>
> Perhaps I'm missing something, but it seems to m
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > How hard would it be to pre-fork an extra backend
>
> How are you going to pass the connection socket to an already-forked
> child process? AFAIK there's no remotely portable way ...
No idea but it seemed like a nice optimization if we could do it
Bruce Momjian <[EMAIL PROTECTED]> writes:
> How hard would it be to pre-fork an extra backend
How are you going to pass the connection socket to an already-forked
child process? AFAIK there's no remotely portable way ...
regards, tom lane
---(end
Bruce Momjian wrote:
>
> How hard would it be to pre-fork an extra backend for the database a
> user just requested so if they next user asks for the same database, the
> backend would already be started?
The only problem I could see is the socket. The pre-forked() back-end would
have to do the
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > How hard would it be to pre-fork an extra backend
> >
> > How are you going to pass the connection socket to an already-forked
> > child process? AFAIK there's no remotely portable way ...
>
> No idea but i
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > How hard would it be to pre-fork an extra backend
> > >
> > > How are you going to pass the connection socket to an already-forked
> > > child process? AFAIK there's no remotely portable way ...
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> On some operating systems, only one child at a time can accept() on the
>> socket. On these, you have to lock around the call to accept().
> But how do you know the client wants the database you have forked? They
> could want a different one.
This a
Tom Lane wrote:
>
> This approach would only work as far as saving the fork() call itself,
> not the backend setup time. Not sure it's worth the trouble. I doubt
> that the fork itself is a huge component of our start time; it's setting
> up all the catalog caches and so forth that's expensive.
Bruce Momjian writes:
> OK, let's assume we have pre-forked backends that do the accept(). One
> enhancement would be for the child to connect to the last requested
> database. If the accept() user wants the same database, it is already
> connected, or at least its cache is loaded. If they wan
At 10:18 AM 15-10-2001 -0400, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
>> Create a small program that makes a few connections to postgresql, does
>> some initialization, preconnects to various DBs (or maybe limited to one DB
>> specified on startup), and listens on one port/socket
On Mon 15 Oct 2001 04:32, you wrote:
DBBalancer (http://www.sourceforge.net/projects/dbbalancer/) does something
like that.
>
> Create a small program that makes a few connections to postgresql, does
> some initialization, preconnects to various DBs (or maybe limited to one DB
> specified on
> Gavin Sherry <[EMAIL PROTECTED]> writes:
>
> > This aside, isn't it possible to just copy the socket and some
> > data about the database required into shared memory and have the preforked
> > children pick the socket up from there.
>
> Ummm No. There's no Unix API for doing so.
>
> You
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > How hard would it be to pre-fork an extra backend
> >
> > How are you going to pass the connection socket to an already-forked
> > child process? AFAIK there's no remotely portable way ...
>
> One of the mechanisms I've
> Bruce Momjian writes:
>
> > OK, let's assume we have pre-forked backends that do the accept(). One
> > enhancement would be for the child to connect to the last requested
> > database. If the accept() user wants the same database, it is already
> > connected, or at least its cache is loaded.
How would authentication and access control be done with a preforking
backend? I personally find a preforking backend desirable, but that's just me.
But if people really want preforking how about not doing it in the backend.
Create a small program that makes a few connections to postgresql, does
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Create a small program that makes a few connections to postgresql, does
> some initialization, preconnects to various DBs (or maybe limited to one DB
> specified on startup), and listens on one port/socket. It might not even
> prefork, just cache connecti
(I'm having trouble with e-mail, so if you get this twice, sorry)
I was looking at some Oracle configuration files today, and it occurred to me
how Postgres can be made to pre-fork, similarly to Oracle.
Oracle has "listener" processes that listen on a port for Oracle clients. The
listeners are c
28 matches
Mail list logo
