Re: PostgreSQL pre-fork speedup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: sdv mailer <sdvmailer(at)yahoo(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Rod Taylor <pg(at)rbt(dot)ca>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>, steve(at)blighty(dot)com, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL pre-fork speedup
Date: 2004-05-06 18:11:30
Message-ID: 2107.1083867090@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

sdv mailer <sdvmailer(at)yahoo(dot)com> writes:
> The point is pre-forking can *potentially* speed up
> connections by 5x as shown in this simplistic
> non-conclusive benchmark.

I think this "benchmark" proves no such thing.

The thing that pgpool is doing is not preforking connections at all, but
re-using prior connections. The important difference is that you are
using a "hot" backend that has already loaded a full working set of
relcache and syscache entries --- and not just any old entries, but
exactly those needed to process your query. (The fact that the pgbench
test uses only a very limited set of queries probably causes this test
to overstate the effect compared to more realistic workloads.)

The profiling that I've done of backend startup shows that cache
initialization accounts for the bulk of the startup delay. And IIRC,
I was just measuring the time needed to be ready to accept the first
query, not the additional effort to fetch query-specific cache entries.
So having a hot backend would make a significant difference, but merely
avoiding the fork wouldn't necessarily.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-05-06 18:26:56 Re: PostgreSQL pre-fork speedup
Previous Message Andreas Pflug 2004-05-06 17:46:16 Re: alter table alter columns vs. domains