Re: Pre-forking backend

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Doug McNaught <doug(at)wireboard(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, sean-pgsql-hackers(at)chittenden(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pre-forking backend
Date: 2001-10-13 19:55:16
Message-ID: 200110131955.f9DJtG008105@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 want another one,
> > we can disconnect and connect to the database they request. This would
> > be portable for all OS's because there is no file descriptor passing.
>
> This is bad because you have hidden "connection pooling" that cannot be
> circumvented, and I guarantee that it will become a problem because "new
> connection" will no longer equal "new connection". Additionally, you're
> assuming a setup were any new connection will connect to a random (from
> the server's point of view) database. I claim these setups are not the
> majority. In fact, any one client application would usually only connect
> to exactly one database, so it might as well keep that connection open.
> For systems were this is not possible for some reason or where different
> databases or connection parameters are really required, there are already
> plenty of solutions available that are tuned or tunable to the situation
> at hand, so your solution would just get in the way. In short, you're
> adding a level of complexity where there is no problem.

Of course, there needs more work on the item. My assumption is that GUC
would control this and that perhaps X requests for the same database
would have to occur before such pre-loading would start. Another idea
is to somehow pass the requested database name before the accept() so
you could have multiple database ready to go and have the proper backend
do the accept().

I realize this is all pie-in-the-sky but I think we need some connection
pooling capability in the backend someday. We are fine with Apache and
PHP becuase they can pool themselves but at some point we have too many
clients reinventing the wheel rather than having our backend do it.

Also, this relates to pre-forking backends and does not related to
re-using backends, which is another nice feature we should have someday.

> > Added to TODO:
>
> I haven't seen a consensus yet.

True. I can remove it or improve it. It is actually:

* Have pre-forked backend pre-connect to last requested database or pass
file descriptor to backend pre-forked for matching database

which mentions passing file descriptors to backends, which we have
discussed and should be recorded for posterity.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bill Studenmund 2001-10-13 23:38:20 Re: Package support for Postgres
Previous Message Bruce Momjian 2001-10-13 19:48:57 Re: PG_DUMP NLS (Russian)