From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | "Alonso García , Bruno Elier" <bealonso(at)indra(dot)es> |
Cc: | Giles Lean <giles(dot)lean(at)pobox(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Libpq Asynchronous Command Processing |
Date: | 2010-05-31 14:52:15 |
Message-ID: | 4C03CD1F.10108@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 31/05/2010 10:34 PM, Alonso García , Bruno Elier wrote:
> If I perform the query using pgadmin I get the same result in both
versions 7.4 and version 8.3.
Just re-read your post and realized you were probably saying that you
get (effectively) the same EXPLAIN ANALYZE results from both, ie this
isn't your problem.
> In fact I have written two test applications that perform the same query, one using the synchronous command processing (PQexec) an one using the asynchronous Command Processing (PQsendQuery / PQconsumeInput / PQisBusy / PQgetResult) and the results are:
> -> synchronous command processing takes less than two seconds to retrieve the result.
So PQexec works fine for you on both 7.4 and 8.3, producing a quick
result no matter which server you run it against?
> -> asynchronous command processing takes more than 120 seconds to retrieve the result.
You mean that this is where you have your problem, and it's fine on both
versions when you use plain PQexec?
Consider using wireshark to examine the network traffic, and see if
there's much activity during your long and slow PQconsumeInput /
PQisBusy loop. The throughput analysis tool is handy for this.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Kretschmer | 2010-05-31 14:56:47 | Re: What Linux edition we should chose? |
Previous Message | Nilesh Govindarajan | 2010-05-31 14:51:47 | Re: What Linux edition we should chose? |