| From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Dimitri <dimitrik(dot)fr(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-12 15:14:31 |
| Message-ID: | 4A099257.9090902@kaltenbrunner.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-05-12 15:18:24 | Re: Any better plan for this query?.. |
| Previous Message | Matthew Wakeling | 2009-05-12 15:05:37 | Re: Any better plan for this query?.. |