Re: What is the practical limitation of no multi-threading? - Mailing list pgsql-general

From Robert B. Easter
Subject Re: What is the practical limitation of no multi-threading?
Date
Msg-id 200112120607.fBC67pH01741@comptechnews.com
Whole thread Raw
In response to Re: What is the practical limitation of no multi-threading?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
I see, there is a postmaster -> postgres symlink! In main/main.c it looks at
argv[0] to see how it is being started and calls the right function,
PostmasterMain() or PostgresMain() - everything is linked into postgres. I
never looked before. Next, I should try to understand its IPC, shared memory,
and other multiprocess details. The source comments and code I've seen so far
are very readable. I'll take a look at some of the FAQs too! :-)) thx

Bob

On Tuesday 11 December 2001 09:55 pm, Bruce Momjian wrote:
> > Not being multithreaded may only be a big deal if your application
> > connects and disconnects from the database at high rates.  In that
> > situation, such an application would suffer the poorer performance of
> > multiprocess servers like Postgres since it is significantly more time
> > consuming to copy the memory management unit (mmu) state, or at least to
> > load a new program image (the backend), than with threads which share mmu
> > state and program image.
>
> Let me mention that we don't load new executables on backend startup.
> We merely fork() the postmaster.  I just checked the FAQ and it seems
> pretty clear.  Please let me know if there is additional info I should
> have there.

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Inserting the current date
Next
From: Philip Rhoades
Date:
Subject: Functions like: GetNextRecord . .