Re: Libpq Asynchronous Command Processing

>> With that analysis, I'd be betting against it being a client problem.
>> (If you wanted, you might confirm that by pointing an old client at
>> the new server.)
>>
>> I'd look into how the data was loaded into the new server and how
>> the database is configured: number of buffers, indexes, and whether
>> analyze has been run or not.
>>
>> It would be strange indeed (possible, but very strange) to find
>> such a slowdown between 7.x and 8.x when the team is preparing
>> to push 9.0 out the door. Surely it would have been known before;
>> therefore it's a practical certatinty that there is something
>> different about the configuration of your two servers.
>
>... or that the planner is making a bad choice when it made a good one
>in 7.x . That's far from unheard of; the downside of a stats-based and
>very complex planner is that sometimes it doesn't make the perfect
>choice. Even with the same stats, etc, it's far from impossible that 7.x
>might hit a good plan when 8.x doesn't.
>
>I mention this because the OP really needs to supply EXPLAIN ANALYZE
>results for the query run via psql (not their custom code) on both their
>7.x and 8.x servers.

If I perform the query using pgadmin I get the same result in both versions 7.4 and version 8.3.
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.
-> asynchronous command processing takes more than 120 seconds to retrieve the result.
Both applications are connecting to the same DB so I don't know why I am getting different results. Well I know that PQIsBusy is returning true so I am not executing PQgetResult.
Bruno,