Skip site navigation (1) Skip section navigation (2)

Re: Libpq Asynchronous Command Processing

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 (view raw or flat)
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

In response to

Responses

pgsql-general by date

Next:From: Andreas KretschmerDate: 2010-05-31 14:56:47
Subject: Re: What Linux edition we should chose?
Previous:From: Nilesh GovindarajanDate: 2010-05-31 14:51:47
Subject: Re: What Linux edition we should chose?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group