Re: random_page_cost vs seq_page_cost
От | Bruce Momjian |
---|---|
Тема | Re: random_page_cost vs seq_page_cost |
Дата | |
Msg-id | 20120207202347.GA7929@momjian.us обсуждение исходный текст |
Ответ на | Re: random_page_cost vs seq_page_cost (Benedikt Grundmann <bgrundmann@janestreet.com>) |
Ответы |
Re: random_page_cost vs seq_page_cost
|
Список | pgsql-hackers |
On Wed, Jan 11, 2012 at 08:26:52AM +0000, Benedikt Grundmann wrote: > (replying just to you) > On 10/01/12 15:22, Greg Smith wrote: > > On 1/5/12 5:04 AM, Benedikt Grundmann wrote: > > That sort of thing is one reason why all attempts so far to set > > random_page_cost based on physical characteristics haven't gone > > anywhere useful. The setting is sort of overloaded right now, it's a > > fuzzy mix of true random seek cost blended with some notion of cache > > percentage. Trying to bring some measurements to bear on it is a less > > effective approach than what people actually do here. Monitor the > > profile of query execution, change the value, see what happens. Use > > that as feedback for what direction to keep going; repeat until > > you're just spinning with no improvements. > > > Thank you very much for the reply it is very interesting. I'm > excited to hear that documentation in that area will improve in > 9.2. It's interesting postgres has remarkable good documentation > but it is a sufficiently complex system that to actually sensible > tune the knobs provided you have to understand quite a lot about > what is going on. A colleague of mine likes to say > "all abstractions leak", which seems very appropriate in this case. Where did you see that there will be an improvement in the 9.2 documentation? I don't see an improvement. I looked over the random_page_cost documentation and remembered I was always concerned about how vague it was about caching effects, so I wrote the attached doc patch to explicity state it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-hackers по дате отправления: