Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Date
Msg-id 25004.894900404@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (Brett McCormick <brett@work.chicken.org>)
Responses Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]  (dg@illustra.com (David Gould))
List 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 by date:

Previous
From: "Maurice Gittens"
Date:
Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Next
From: Brett McCormick
Date:
Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]