>> 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, -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
