From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Benedikt Grundmann <bgrundmann(at)janestreet(dot)com> |
Cc: | Greg Smith <greg(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: random_page_cost vs seq_page_cost |
Date: | 2012-02-07 20:23:47 |
Message-ID: | 20120207202347.GA7929@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment | Content-Type | Size |
---|---|---|
random | text/plain | 746 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-02-07 20:31:56 | Re: Text-any concatenation volatility acting as optimization barrier |
Previous Message | Marti Raudsepp | 2012-02-07 20:18:13 | Text-any concatenation volatility acting as optimization barrier |