Re: profiling connection overhead

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: profiling connection overhead
Дата
Msg-id 4CFDA097.8070702@agliodbs.com
обсуждение исходный текст
Ответ на Re: profiling connection overhead  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: profiling connection overhead  (Craig Ringer <craig@postnewspapers.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Itagaki Takahiro
Дата:
Сообщение: Re: Per-column collation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: wal_sender_delay is still required?