Re: profiling connection overhead - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: profiling connection overhead
Date
Msg-id 4CFDA097.8070702@agliodbs.com
Whole thread Raw
In response to Re: profiling connection overhead  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: profiling connection overhead  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-hackers
> It seems plausible to fix the first one, but how would you fix the
> second one?  You either allow SET ROLE (which you need, to support the
> pooler changing authorization), or you don't.  There doesn't seem to be
> a usable middleground.

Well, this is why such a pooler would *have* to be built into the
backend.  It would need to be able to SET ROLE even though SET ROLE
would not be accepted over the client connection.  We'd also need
bookkeeping to track the ROLE (and other GUCs) of each client connection
and reset them whenever that client connection switches back.

Mind you, I'm not entirely convinced that the end result of this would
be performant.  And they would certainly be complicated.  I think that
we should start by dealing with the simplest situation, ignoring SET
ROLE and GUC issues for now.

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: Per-column collation
Next
From: Tom Lane
Date:
Subject: Re: wal_sender_delay is still required?