DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
	b=BqZULkTmVqHmrsI+u4G1I4A76xELsK+w5MQXA0bDE6XlbRKTeO8eMbzPSK9GHFE9oWeV+tuOs1NCf5CFDZl2ydQyjKD7JoAra7EUBnd6vWgX8e2/pPPr6Z54MXfIKac/T+XYjWnA5yVVwvv+4kDEgXNZnht/O+if7jqP5Gefgr0=
Message-ID: <456FA235.1070406@gmail.com>
Date: Fri, 01 Dec 2006 14:32:05 +1100
From: Chris <dmagick@gmail.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Tobias Brox <tobias@nordicbet.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Defining performance.
References: <20061201011554.GA27123@oppetid.no>
In-Reply-To: <20061201011554.GA27123@oppetid.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tobias Brox wrote:
> [nospam@hardgeus.com - Thu at 06:37:12PM -0600]
>> As my dataset has gotten larger I have had to throw more metal at the
>> problem, but I have also had to rethink my table and query design.  Just
>> because your data set grows linearly does NOT mean that the performance of
>> your query is guaranteed to grow linearly!  A sloppy query that runs OK
>> with 3000 rows in your table may choke horribly when you hit 50000.
> 
> Then some limit is hit ... either the memory cache, or that the planner
> is doing an unlucky change of strategy when hitting 50000.

Not really. A bad query is a bad query (eg missing a join element). It 
won't show up for 3000 rows, but will very quickly if you increase that 
by a reasonable amount. Even as simple as a missing index on a join 
column won't show up for a small dataset but will for a larger one.

It's a pretty common mistake to assume that a small dataset will behave 
exactly the same as a larger one - not always the case.

-- 
Postgresql & php tutorials
http://www.designmagick.com/