Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 99314133798E for ; Wed, 13 Apr 2011 21:03:37 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 66697-09 for ; Thu, 14 Apr 2011 00:03:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 4C4581337B2F for ; Wed, 13 Apr 2011 21:03:16 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p3E039GL001810; Wed, 13 Apr 2011 20:03:09 -0400 (EDT) To: Nathan Boley cc: Claudio Freire , Kevin Grittner , Ogden , Tomas Vondra , pgsql-performance@postgresql.org Subject: Re: Performance In-reply-to: References: <20110412171855.GA14292@tux> <4DA496FA.3070908@fuzzy.cz> <8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com> <4DA4BFA2.5060601@fuzzy.cz> <4DA4D40A.4010200@fuzzy.cz> <4DA56DA8020000250003C783@gw.wicourts.gov> Comments: In-reply-to Nathan Boley message dated "Wed, 13 Apr 2011 15:05:14 -0700" Date: Wed, 13 Apr 2011 20:03:09 -0400 Message-ID: <1809.1302739389@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201104/205 X-Sequence-Number: 43267 Nathan Boley writes: > FWIW, awhile ago I wrote a simple script to measure this and found > that the *actual* random_page / seq_page cost ratio was much higher > than 4/1. That 4:1 ratio is based on some rather extensive experimentation that I did back in 2000. In the interim, disk transfer rates have improved quite a lot more than disk seek times have, and the CPU cost to process a page's worth of data has also improved compared to the seek time. So yeah, you'd likely get a higher number if you redid those experiments on modern hardware (at least assuming it was rotating media and not SSD). On the other hand, the effects of caching push the numbers in the other direction, and modern machines also have a lot more RAM to cache in than was typical ten years ago. I'm not sure how much point there is in trying to improve the default number in the abstract --- we'd really need to have a more robust model of cache effects before I'd trust any automatic tuning procedure to set the value for me. regards, tom lane