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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Дата
Msg-id 25004.894900404@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Brett McCormick <brett@work.chicken.org>)
Ответы Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (dg@illustra.com (David Gould))
Список pgsql-hackers
Meanwhile, *I* missed the point about Brett's second comment :-(

Brett McCormick <brett@work.chicken.org> writes:
> There will have to be some sort of arg parsing in any case,
> considering that you can pass configurable arguments to the backend..

If we do the sort of change David and I were just discussing, then the
pre-spawned backend would become responsible for parsing and dealing
with the PGOPTIONS portion of the client's connection request message.
That's just part of shifting the authentication handshake code from
postmaster to backend, so it shouldn't be too hard.

BUT: the whole point is to be able to initialize the backend before it
is connected to a client.  How much of the expensive backend startup
work depends on having the client connection options available?
Any work that needs to know the options will have to wait until after
the client connects.  If that means most of the startup work can't
happen in advance anyway, then we're out of luck; a pre-started backend
won't save enough time to be worth the effort.  (Unless we are willing
to eliminate or redefine the troublesome options...)

            regards, tom lane

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

Предыдущее
От: "Maurice Gittens"
Дата:
Сообщение: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Следующее
От: Brett McCormick
Дата:
Сообщение: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]