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]
|
Список | 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 по дате отправления: