Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]

Поиск
Список
Период
Сортировка
От dg@illustra.com (David Gould)
Тема Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Дата
Msg-id 9805120603.AA14934@hawk.illustra.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Bruce Momjian:
> > I was thinking that we would have a pool of ready servers _per_database_.
> > That is, we would be able to configure say 8 servers in a particular DB, and
> > say 4 in another DB etc. These servers could run most of the way through
> > initialization (open catalogs, read in syscache etc). Then they would wait
> > until a connection for the desired DB was handed to them by the postmaster.
> >
>
> OK, but how do you invalidate the catalog items that have changed from
> the startup to the time it gets the client connection?

Same way we always do?

Is there any reason the "ready" servers can't track the Shared Invalidate
cache like any other backend? Maybe they have to time out their wait for a
socket every few seconds and process SI updates, but it should be possible
to make this work. Perhaps not as easy as all that, but certainly doable I
would guess.

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
 and someone who knows less will correct me if I'm right."
               --David Palmer (palmer@tybalt.caltech.edu)

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

Предыдущее
От: Carlos Navarro Garcia
Дата:
Сообщение: Portals again
Следующее
От: "Göran Thyni"
Дата:
Сообщение: Re: [HACKERS] mmap and MAP_ANON