Re: [HACKERS] fork/exec for backend

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] fork/exec for backend
Дата
Msg-id 199801250024.TAA21721@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] fork/exec for backend  (Tom <tom@sdf.com>)
Ответы Re: [HACKERS] fork/exec for backend  (Tom <tom@sdf.com>)
Список pgsql-hackers
>
>
> On 24 Jan 1998, Goran Thyni wrote:
>
> > Fork on modern unices (linux and (a think) *BSD) cost
> > almost nothing (in time and memory) thanks to COW (copy-on-write).
> > Exec in expensive as it breaks COW.
>
>   Not so.  Modern Unixs will share executable address space between
> processes.  So if you fork and exec 10 identical programs, they will share
> most address space.
>
>   If you want to speed this up, link postgresql static.  This makes exec()
> cost almost nothing too.  postgresql becomes its own best shared library.
>
>   Again, this only applies to "modern" systems, but FreeBSD definitely has
> this behaviour.

This is very OS-specific.  SunOS-style shared libraries do have a
noticable overhead for each function call.  In fact, even though these
are part of BSD44 source, BSDI does not use them, and uses a more crude
shared library jump table, similar to SVr3 shared libraries because of
the SunOS shared library overhead.

I think FreeBSD and Lunix use SunOS style shared libraries, often called
dynamic shared libraries because you can change the function while the
binary is running if you are realy careful.

--
Bruce Momjian
maillist@candle.pha.pa.us

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] fork/exec for backend
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: Browsing the tables and why pgsql does not perform well