Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 7E0A99FA17A for ; Fri, 1 Dec 2006 00:42:16 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 10743-05 for ; Fri, 1 Dec 2006 00:42:12 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from lynet.oppetid.no (oppetid.no [80.65.51.2]) by postgresql.org (Postfix) with ESMTP id 4616F9FA100 for ; Fri, 1 Dec 2006 00:42:12 -0400 (AST) Received: by lynet.oppetid.no (Postfix, from userid 1019) id 974A9119C81; Fri, 1 Dec 2006 05:03:26 +0100 (CET) Date: Fri, 1 Dec 2006 05:03:26 +0100 From: Tobias Brox To: Chris Cc: Tobias Brox , pgsql-performance@postgresql.org Subject: Re: Defining performance. Message-ID: <20061201040326.GA27833@oppetid.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Group Nordicbet User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/1 X-Sequence-Number: 22057 [Chris - Fri at 02:32:05PM +1100] > 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. Ok, you're talking about O(n^2) and such stuff :-) > 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. No. :-) We had the worst experience when launching our product - it had been stress tested, but only by increasing the number of customers, not by increasing the overall size of the data set available for browsing. When opening the web pages for the public, this data set was already some ten-hundred times bigger than in the version enduring the stress tests - and the servers had no chances processing all the traffic. The worst bottle neck was not the database this time, but some horror algorithm one of the programmers had sneaked in ... poorly documented, cryptically programmed, slow ... and since I never understood that algorithm, I can only guess it must have been of O(n^2).