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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brett McCormick <brett(at)work(dot)chicken(dot)org>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Date: 1998-05-11 15:26:44
Message-ID: 25004.894900404@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Meanwhile, *I* missed the point about Brett's second comment :-(

Brett McCormick <brett(at)work(dot)chicken(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brett McCormick 1998-05-11 15:32:16 Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]
Previous Message Maurice Gittens 1998-05-11 15:18:38 Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh]