Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 565841337B67
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 13 Apr 2011 19:15:41 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 45436-08
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 13 Apr 2011 22:15:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from gw.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by mail.postgresql.org (Postfix) with ESMTP id 22C6C133798E
	for <pgsql-performance@postgresql.org>;
	Wed, 13 Apr 2011 19:15:33 -0300 (ADT)
Received: from Courts-MTA by gw.wicourts.gov
	with Novell_GroupWise; Wed, 13 Apr 2011 17:15:33 -0500
Message-Id: <4DA5DA33020000250003C7CC@gw.wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 8.0.1 
Date: Wed, 13 Apr 2011 17:15:31 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Claudio Freire" <klaussfreire@gmail.com>,
	"Nathan Boley" <npboley@gmail.com>
Cc: "Ogden" <lists@darkstatic.com>,"Tomas Vondra" <tv@fuzzy.cz>,
	<pgsql-performance@postgresql.org>
Subject: Re: Performance
References: <DF2D5436-117C-4D02-9B3C-A55723B7DDE1@darkstatic.com>
	<20110412171855.GA14292@tux>
	<FC3A3A2B-3ECB-41BA-8F94-356D6FED3695@darkstatic.com>
	<4DA496FA.3070908@fuzzy.cz>
	<8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com>
	<4DA4BFA2.5060601@fuzzy.cz>
	<B93DFBBB-DA56-4044-A508-0B7E4A2CFD28@darkstatic.com>
	<4DA4D40A.4010200@fuzzy.cz>
	<A0B9339E-9D58-4842-A206-050B773360B6@darkstatic.com>
	<4DA56DA8020000250003C783@gw.wicourts.gov>
	<BANLkTinJqXqErAtQg--1MOaw2LJNFZmwOg@mail.gmail.com>
	<BANLkTimyWkoX8Dj=4CKAjhY82ibru-An7g@mail.gmail.com>
In-Reply-To: <BANLkTimyWkoX8Dj=4CKAjhY82ibru-An7g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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/201
X-Sequence-Number: 43263

Nathan Boley <npboley@gmail.com> wrote:
 
> The problem is that caching effects have a large effect on the
> time it takes to access a random page, and caching effects are
> very workload dependent. So anything automated would probably need
> to optimize the parameter values over a set of 'typical' queries,
> which is exactly what a good DBA does when they set
> random_page_cost...
 
Another database product I've used has a stored procedure you can
run to turn on monitoring of workload, another to turn it off and
report on what happened during the interval.  It drags performance
enough that you don't want to leave it running except as a tuning
exercise, but it does produce very detailed statistics and actually
offers suggestions on what you might try tuning to improve
performance.  If someone wanted to write something to deal with this
issue, that seems like a sound overall strategy.
 
-Kevin