Re: Any better plan for this query?.. - Mailing list pgsql-performance

From Stefan Kaltenbrunner
Subject Re: Any better plan for this query?..
Date
Msg-id 4A099257.9090902@kaltenbrunner.cc
Whole thread Raw
In response to Re: Any better plan for this query?..  (Matthew Wakeling <matthew@flymine.org>)
List 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 by date:

Previous
From: Matthew Wakeling
Date:
Subject: Re: Any better plan for this query?..
Next
From: Tom Lane
Date:
Subject: Re: Any better plan for this query?..