Re: Libpq Asynchronous Command Processing
От | Craig Ringer |
---|---|
Тема | Re: Libpq Asynchronous Command Processing |
Дата | |
Msg-id | 4C03B1B8.9070907@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: Libpq Asynchronous Command Processing (Giles Lean <giles.lean@pobox.com>) |
Ответы |
Re: Libpq Asynchronous Command Processing
|
Список | pgsql-general |
On 31/05/2010 5:41 PM, Giles Lean wrote: > =?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. ... 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. -- Craig Ringer
В списке pgsql-general по дате отправления: