Re: Odd problem with performance in duplicate database
От | Ron Johnson |
---|---|
Тема | Re: Odd problem with performance in duplicate database |
Дата | |
Msg-id | 1060641748.23325.62.camel@haggis обсуждение исходный текст |
Ответ на | Re: Odd problem with performance in duplicate database (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Odd problem with performance in duplicate database
|
Список | pgsql-performance |
On Mon, 2003-08-11 at 17:03, Josh Berkus wrote: > 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? If the databases are on different machines, maybe the postgres.conf or pg_hba.conf files are different, and the buffer counts is affect- ing the optimizer? -- +---------------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA | | | | "Man, I'm pretty. Hoo Hah!" | | Johnny Bravo | +---------------------------------------------------------------+
В списке pgsql-performance по дате отправления: