From: | Paul Ramsey <pramsey(at)refractions(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | sdv mailer <sdvmailer(at)yahoo(dot)com> |
Subject: | Re: PostgreSQL pre-fork speedup |
Date: | 2004-05-03 15:33:19 |
Message-ID: | 4096663F.3050101@refractions.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
sdv mailer wrote:
> Instead, there's a big need to
> create a new connection on
> every query and with PostgreSQL needing to fork on
> every incoming connection
> can be quite slow.
Really? My general experience has beent that forking/connection setup
times are very good with PgSQL. Do not assume your Oracle experience
transfers directly over -- Oracle has very large connection time
overheads, PgSQL does not.
> This could be a big win since even a moderate
> improvement at the connection
> level will affect almost every user. Any chance of
> that happening for 7.5?
Only if you do it yourself, probably. The calculation of the developers
appears to be that the amount of time spent by the database on
fork/connect will generally be dwarfed by the amount of time spent by
the database actually doing work (this being a database, the actual
workloads required of the backend are much higher than, say, for a web
server). So the operational benefit of adding the complexity of a
pre-fork system is not very high. And if you have the rare workload
where a pre-fork actually *would* speed things up a great deal, you can
solve the problem yourself with a connection-pooling middleware.
--
__
/
| Paul Ramsey
| Refractions Research
\_
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2004-05-03 15:38:00 | Re: mingw configure failure workaround |
Previous Message | Tom Lane | 2004-05-03 15:30:06 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |