Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Stefan Kaltenbrunner
Тема Re: Any better plan for this query?..
Дата
Msg-id 4A099257.9090902@kaltenbrunner.cc
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Matthew Wakeling <matthew@flymine.org>)
Список pgsql-performance
Matthew Wakeling wrote:
> On Tue, 12 May 2009, Simon Riggs wrote:
>>> won't connect operations be all handled by a
>>> single thread - the parent postmaster?
>>
>> No, we spawn then authenticate.
>
> But you still have a single thread doing the accept() and spawn. At some
> point (maybe not now, but in the future) this could become a bottleneck
> given very short-lived connections.

well the main cost is backend startup and that one is extremely
expensive (compared to the cost of a simple query and also depending on
the OS). We have more overhead there than other databases (most notably
MySQL) hence what prompted my question on how the benchmark was operating.
For any kind of workloads that contain frequent connection
establishments one wants to use a connection pooler like pgbouncer(as
said elsewhere in the thread already).


Stefan

В списке pgsql-performance по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Any better plan for this query?..