> Bruce Guenter <bruceg@em.ca> writes:
> > [ some very interesting datapoints ]
> >
> > So, forking a process with lots of data is expensive. However, most of
> > the PostgreSQL data is in a SysV IPC shared memory segment, which
> > shouldn't affect the fork numbers.
>
> I believe (but don't have numbers to prove it) that most of the present
> backend startup time has *nothing* to do with thread vs process
> overhead. Rather, the primary startup cost has to do with initializing
> datastructures, particularly the system-catalog caches. A backend isn't
> going to get much real work done until it's slurped in a useful amount
> of catalog cache --- for example, until it's got the cache entries for
> pg_class and the indexes thereon, it's not going to accomplish anything
> at all.
>
> Switching to a thread model wouldn't help this cost a bit, unless
> we also switch to a shared cache model. That's not necessarily a win
> when you consider the increased costs associated with cross-backend
> or cross-thread synchronization needed to access or update the cache.
> And if it *is* a win, we could get most of the same benefit in the
> multiple-process model by keeping the cache in shared memory.
Of course, we would also have to know which database was being used
next. Each database's system catalog can be different.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026