Re: Odd problem with performance in duplicate database

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Odd problem with performance in duplicate database
Дата
Msg-id 200308111503.46794.josh@agliodbs.com
обсуждение исходный текст
Ответ на Odd problem with performance in duplicate database  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Odd problem with performance in duplicate database  (Ron Johnson <ron.l.johnson@cox.net>)
Список pgsql-performance
Folks,

More followup on this:

The crucial difference between the two execution plans is this clause:

test db has:
->  Seq Scan on case_clients  (cost=0.00..3673.48 rows=11274 width=11) (actual
time=0.02..302.20 rows=8822 loops=855)

whereas live db has:
->  Index Scan using idx_caseclients_case on case_clients  (cost=0.00..5.10
rows=1 width=11) (actual time=0.03..0.04 rows=1 loops=471)

using an enable_seqscan = false fixes this, but is obviously not a long-term
solution.

I've re-created the test system from an immediate copy of the live database,
and checked that the the main tables and indexes were reproduced faithfully.

Lowering random_page_cost seems to do the trick.  But I'm still mystified; why
would one identical database pick a different plan than its copy?

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco


В списке pgsql-performance по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Odd problem with performance in duplicate database
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Perfomance Tuning