Re: reducing random_page_cost from 4 to 2 to force index scan
От | Kevin Grittner |
---|---|
Тема | Re: reducing random_page_cost from 4 to 2 to force index scan |
Дата | |
Msg-id | 4DCD2A1C020000250003D6E0@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: reducing random_page_cost from 4 to 2 to force index scan (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-performance |
Robert Haas <robertmhaas@gmail.com> wrote: > We've talked in the past (and I still think it's a good idea, but > haven't gotten around to doing anything about it) about adjusting > the planner to attribute to each relation the percentage of its > pages which we believe we'll find in cache. Although many > complicated ideas for determining that percentage have been > proposed, my favorite one is fairly simple: assume that small > relations will be mostly or entirely cached, and that big ones > won't be. Allow the administrator to override the result on a > per-relation basis. It's difficult to imagine a situation where > the planner should assume that a relation with only handful of > pages isn't going to be cached. Even if it isn't, as soon as > someone begins accessing it, it will be. Simple as the heuristic is, I bet it would be effective. While one can easily construct a synthetic case where it falls down, the ones I can think of aren't all that common, and you are suggesting an override mechanism. -Kevin
В списке pgsql-performance по дате отправления: