Re: PostgreSQL pre-fork speedup

Поиск
Список
Период
Сортировка
От Paul Ramsey
Тема Re: PostgreSQL pre-fork speedup
Дата
Msg-id 4096663F.3050101@refractions.net
обсуждение исходный текст
Ответ на PostgreSQL pre-fork speedup  (sdv mailer <sdvmailer@yahoo.com>)
Ответы Re: PostgreSQL pre-fork speedup
Re: PostgreSQL pre-fork speedup
Список 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     \_


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
Следующее
От: Philip Warner
Дата:
Сообщение: Re: ANALYZE locks pg_listener in EXCLUSIVE for long