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  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index 3a84321..19e3e36
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** SET ENABLE_SEQSCAN TO OFF;
*** 2590,2595 ****
--- 2590,2597 ----
         <para>
          Sets the planner's estimate of the cost of a
          non-sequentially-fetched disk page.  The default is 4.0.
+         (The default is lower than the typical difference between random
+         and sequential storage access speed because of caching effects.)
          This value can be overridden for tables and indexes in a particular
          tablespace by setting the tablespace parameter of the same name
          (see <xref linkend="sql-altertablespace">).
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to