Message-ID: <4DA63125.5070106@fuzzy.cz>
Date: Thu, 14 Apr 2011 01:26:29 +0200
From: Tomas Vondra <tv@fuzzy.cz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.13) Gecko/20101219 Lightning/1.0b3pre Thunderbird/3.1.7
MIME-Version: 1.0
To: 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>
	<4DA6216E.9020907@fuzzy.cz>
	<BANLkTim_m-oz3UMXEKUdFjWJ6uuAza79cw@mail.gmail.com>
In-Reply-To: <BANLkTim_m-oz3UMXEKUdFjWJ6uuAza79cw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dne 14.4.2011 01:10, Claudio Freire napsal(a):
> On Thu, Apr 14, 2011 at 12:19 AM, Tomas Vondra <tv@fuzzy.cz> wrote:
>>
>> Another issue is that when measuring multiple values (processing of
>> different requests), the decisions may be contradictory so it really
>> can't be fully automatic.
>>
> 
> I don't think it's soooo dependant on workload. It's dependant on
> access patterns (and working set sizes), and that all can be
> quantified, as opposed to "workload".

Well, think about a database that's much bigger than the available RAM.

Workload A: Touches just a very small portion of the database, to the
'active' part actually fits into the memory. In this case the cache hit
ratio can easily be close to 99%.

Workload B: Touches large portion of the database, so it hits the drive
very often. In this case the cache hit ratio is usually around RAM/(size
of the database).

So yes, it may be very workload dependent. In the first case you may
actually significantly lower the random_page_cost (even to
seq_page_cost) and it's going to be quite fast (thanks to the cache).

If you do the same thing with workload B, the database is going to burn.

I'm not saying it's not possible to do some autotuning, but it's a bit
tricky and it's not just about hardware. The workload *is* a very
important part of the equation.

But I have to admit this post probably sounds like an overengineering.
If you can develop something simple (even if that does not consider
workload at all), it might be a useful starting point. If I could help
you in any way with this, let me know.

regards
Tomas