X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id E723752A7B for ; Tue, 12 Jul 2005 15:01:03 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 29766-05 for ; Tue, 12 Jul 2005 18:00:50 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by svr1.postgresql.org (Postfix) with ESMTP id 9845752A2C for ; Tue, 12 Jul 2005 15:00:49 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id 71so8059wra for ; Tue, 12 Jul 2005 11:00:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HAJcu+o9+qAhSOaA1JM+cpPsdvf92FdqCF+Rs1PROlRtFquyWg1x46tuQOfTbyU1H5hzbdW8RKRpajP2piuzpZWHGkgkxmE7owzf+y0dt/kD5WLXUJBrOGKB2zm4n9dqrjgx2kuiQIru5doXEQyrPQ6AK2dBYpf4L0PPav95Ovs= Received: by 10.54.106.13 with SMTP id e13mr31902wrc; Tue, 12 Jul 2005 11:00:49 -0700 (PDT) Received: by 10.54.22.15 with HTTP; Tue, 12 Jul 2005 11:00:49 -0700 (PDT) Message-ID: Date: Tue, 12 Jul 2005 13:00:49 -0500 From: Matthew Nuzum Reply-To: newz@bearfruit.org To: Yves Vindevogel Subject: Re: Projecting currentdb to more users Cc: pgsql-performance@postgresql.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.985 tagged_above=0 required=5 tests=AWL, RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: X-Archive-Number: 200507/123 X-Sequence-Number: 13364 On 7/12/05, Yves Vindevogel wrote: > Hi, >=20 > We have a couple of database that are identical (one for each customer). > They are all relatively small, ranging from 100k records to 1m records. > There's only one main table with some smaller tables, a lot of indexes > and some functions. >=20 > I would like to make an estimation of the performance, the diskspace > and other related things, > when we have database of for instance 10 million records or 100 million > records. >=20 > Is there any math to be done on that ? Its pretty easy to make a database run fast with only a few thousand records, or even a million records, however things start to slow down non-linearly when the database grows too big to fit in RAM. I'm not a guru, but my attempts to do this have not been very accurate. Maybe (just maybe) you could get an idea by disabling the OS cache on the file system(s) holding the database and then somehow fragmenting the drive severly (maybe by putting each table in it's own disk partition?!?) and measuring performance. On the positive side, there are a lot of wise people on this list who have +++ experience optimzing slow queries on big databases. So queries now that run in 20 ms but slow down to 7 seconds when your tables grow will likely benefit from optimizing. --=20 Matthew Nuzum www.bearfruit.org