Re: PostgreSQL pre-fork speedup - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: PostgreSQL pre-fork speedup
Date
Msg-id 1083767093.54823.33.camel@jester
Whole thread Raw
In response to Re: PostgreSQL pre-fork speedup  ("Peter Galbavy" <peter.galbavy@knowtion.net>)
Responses Re: PostgreSQL pre-fork speedup  (Greg Stark <gsstark@mit.edu>)
Re: PostgreSQL pre-fork speedup  (Jonathan Gardner <jgardner@jonathangardner.net>)
List pgsql-hackers
> And "preforking" makes this different, how ? Perhaps having a pool of
> processes ready to be handed a query to a specific database, where you
> configure N connections to db1, M to db2 etc. still means lots of resource
> usage. In effect a preforked database server *is* an idle connection, just
> without the TCP establishment and teardown sequence which is negligable on
> modern platforms - and even if it were not negligable, it would be
> effectively identical regardless of the chosen DB platform.

In theory, it should drastically reduce the number of idle connections
for poor connection pooling on the other end.

The problem are pools for Apache that establish 1 connection per Apache
backend. 100 Apache backends means 100 backend connections (50 of which
may be idle as not all pages use the database). Multiply that by 40
webservers and you have a real mess of idle connections.

Cutting that count down to 10 idlers in total by having PostgreSQL
prefork a specific database would make a significant difference.

The other (preferable) alternative is to convince Apache to use a common
connection pool per server rather than per Apache backend.




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Multiple Xids in PGPROC?
Next
From: Greg Stark
Date:
Subject: Re: Multiple Xids in PGPROC?