At 02:53 PM 1/4/06, Sean Davis wrote:
>On 1/4/06 2:40 PM, "Kevin Crenshaw" <kcrenshaw@viscient.com> wrote:
>
> > Roland,
> >
> > I wanted to reply to your post separately. I toyed with using pg_user to
> > store user information, but it did not work. I tried to use pg_user to
> > store user acct info and then use a 'user_detail' table to store additional
> > details but I got an error stating that pg_user is not a table (this
> > occurred when I tried to use the 'usesysid' column as a foreign key in my
> > user_detail table).
> >
> > I think that the best solution - given the discussion thus far - is to
> have
> > a separate pg user that the web app will use to access the database, and
> > create a 'users' table in the db to store the web app usernames and
> > passwords etc...
>
>This hasn't been mentioned yet (and probably isn't that important for all
>but the most demanding web apps), but one way to significantly speed up web
>apps is to use persistent database connections (they are not closed after
>each request). This is not really feasible with a multiple-db-user setup.
NOT TRUE. To be correct, your statement must be a bit longer. The
connections are not closed after each request within each child process of
the web server. If you run apache and there are 100 child processes, there
can be up to 100 open "persistent" database connections. In many cases
where database and webserver are on the same box there is little time
difference between persistent and non-persistent connections; but in
general there are many variables and each host should do their own timing
tests.