Re: PostgreSQL pre-fork speedup

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Peter Galbavy <peter(dot)galbavy(at)knowtion(dot)net>
Cc: sdv mailer <sdvmailer(at)yahoo(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL pre-fork speedup
Date: 2004-05-05 14:24:54
Message-ID: 1083767093.54823.33.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-05-05 14:36:36 ALTER TABLE TODO items
Previous Message Tom Lane 2004-05-05 13:55:35 Re: [PATCHES] Function to do runtime relative directory