Re: Libpq Asynchronous Command Processing

Поиск
Список
Период
Сортировка
От Giles Lean
Тема Re: Libpq Asynchronous Command Processing
Дата
Msg-id 20100531094141.5806.qmail@sapphire.netherstone.net
обсуждение исходный текст
Ответ на Libpq Asynchronous Command Processing  (Alonso García , Bruno Elier <bealonso@indra.es>)
Ответы Re: Libpq Asynchronous Command Processing  (Craig Ringer <craig@postnewspapers.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Alonso García , Bruno Elier
Дата:
Сообщение: Libpq Asynchronous Command Processing
Следующее
От: Jasen Betts
Дата:
Сообщение: Re: 110,000,000 rows