Re: Libpq Asynchronous Command Processing - Mailing list pgsql-general

From Giles Lean
Subject Re: Libpq Asynchronous Command Processing
Date
Msg-id 20100531094141.5806.qmail@sapphire.netherstone.net
Whole thread Raw
In response to Libpq Asynchronous Command Processing  (Alonso García , Bruno Elier <bealonso@indra.es>)
Responses Re: Libpq Asynchronous Command Processing  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
=?iso-8859-1?Q?Alonso_Garc=EDa_=2C_Bruno_Elier?= <bealonso@indra.es> wrote:

> And the problems I am finding are the following:
> ->Queries from the client to the new DB server take a lot of time.
> ->Queries from the client to the old DB server are fast.
> ->The same query takes 150 secs in one case an 1 sec in the other case.

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.

Giles

pgsql-general by date:

Previous
From: Alonso García , Bruno Elier
Date:
Subject: Libpq Asynchronous Command Processing
Next
From: Jasen Betts
Date:
Subject: Re: 110,000,000 rows