Re: reducing random_page_cost from 4 to 2 to force index scan
От | Robert Haas |
---|---|
Тема | Re: reducing random_page_cost from 4 to 2 to force index scan |
Дата | |
Msg-id | BANLkTi=BTJ56m-OozcD8fH2kkHOqmA4fHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: reducing random_page_cost from 4 to 2 to force index scan (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: reducing random_page_cost from 4 to 2 to force index
scan
|
Список | pgsql-performance |
On Fri, May 13, 2011 at 4:13 PM, Josh Berkus <josh@agliodbs.com> wrote: > Instead, we should be fixing the formulas these are based on and leaving > RPC alone. > > For any data page, there are actually four costs associated with each > tuple lookup, per: All true. I suspect that in practice the different between random and sequential memory page costs is small enough to be ignorable, although of course I might be wrong. I've never seen a database that was fully cached in memory where it was necessary to set random_page_cost>seq_page_cost to get good plans -- no doubt partly because even if the pages were consecutive on disk, there's no reason to suppose they would be so in memory, and we certainly wouldn't know one way or the other at planning time. But I agree we should add a cached_page_cost as part of all this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-performance по дате отправления: