Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 50626D7C8EC for ; Sun, 12 Feb 2012 16:02:17 -0400 (AST) Received: from smtp.01.com ([199.36.142.181]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rwfck-00046k-BE for pgsql-performance@postgresql.org; Sun, 12 Feb 2012 20:02:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1C7613F4C9F for ; Sun, 12 Feb 2012 14:02:00 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07x-HkvfOFVc for ; Sun, 12 Feb 2012 14:01:59 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E3E2C3F4D78 for ; Sun, 12 Feb 2012 14:01:59 -0600 (CST) Received: from mail-1.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id AD15D3F4BBC; Sun, 12 Feb 2012 14:01:59 -0600 (CST) Date: Sun, 12 Feb 2012 14:01:59 -0600 (CST) From: Joshua Berkus To: Jeff Janes Cc: Peter van Hardenberg , pgsql-performance@postgresql.org, Scott Marlowe Message-ID: <873667728.6754.1329076919645.JavaMail.root@mail-1.01.com> In-Reply-To: Subject: Re: random_page_cost = 2.0 on Heroku Postgres MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.36.197.35] X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - FF3.0 (Linux)/7.1.3_GA_3346) X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201202/109 X-Sequence-Number: 46281 > Is there an easy and unintrusive way to get such a metric as the > aggregated query times? And to normalize it for how much work > happens > to have been doing on at the time? You'd pretty much need to do large-scale log harvesting combined with samples of query concurrency taken several times per minute. Even that won't "normalize" things the way you want, though, since all queries are not equal in terms of the amount of data they hit. Given that, I'd personally take a statistical approach. Sample query execution times across a large population of servers and over a moderate amount of time. Then apply common tests of statistical significance. This is why Heroku has the opportunity to do this in a way that smaller sites could not; they have enough servers to (probably) cancel out any random activity effects. --Josh Berkus