Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 0DFCD2E2F55 for ; Tue, 27 Nov 2007 19:06:44 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 86114-04 for ; Tue, 27 Nov 2007 19:06:28 -0400 (AST) Received: from linus.numail.org (mail.numail.org [216.130.152.7]) by postgresql.org (Postfix) with ESMTP id 7C7AE2E2EFA for ; Tue, 27 Nov 2007 19:06:37 -0400 (AST) Received: (qmail 28616 invoked by uid 0); 27 Nov 2007 23:06:35 -0000 Received: from 72.15.64.64 by linus.numail.org (envelope-from , uid 101) with qmail-scanner-1.23 (fsecure: 4.50/2111/fprot(2004-10-21)/avp(2004-10-21). Clear:RC:1(72.15.64.64):. Processed in 0.084293 secs); 27 Nov 2007 23:06:35 -0000 Received: from unknown (HELO ?24.25.1.100?) (72.15.64.64) by mail.numail.org with AES256-SHA encrypted SMTP; 27 Nov 2007 23:06:34 -0000 Message-ID: <474CA2FA.2020201@laotraesquina.com.ar> Date: Tue, 27 Nov 2007 18:06:34 -0500 From: Pablo Alcaraz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pgsql-performance Subject: Re: TB-sized databases References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com> <474B1407.3090607@laotraesquina.com.ar> <474B1B8C.1030505@gmail.com> <4544e0330711271218h56ce4cc3p280a9fefff24583d@mail.gmail.com> <1196197045.4246.1154.camel@ebony.site> In-Reply-To: <1196197045.4246.1154.camel@ebony.site> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/328 X-Sequence-Number: 27743 Simon Riggs wrote: > All of those responses have cooked up quite a few topics into one. Large > databases might mean text warehouses, XML message stores, relational > archives and fact-based business data warehouses. > > The main thing is that TB-sized databases are performance critical. So > it all depends upon your workload really as to how well PostgreSQL, or > another other RDBMS vendor can handle them. > > > Anyway, my reason for replying to this thread is that I'm planning > changes for PostgreSQL 8.4+ that will make allow us to get bigger and > faster databases. If anybody has specific concerns then I'd like to hear > them so I can consider those things in the planning stages it would be nice to do something with selects so we can recover a rowset on huge tables using a criteria with indexes without fall running a full scan. In my opinion, by definition, a huge database sooner or later will have tables far bigger than RAM available (same for their indexes). I think the queries need to be solved using indexes enough smart to be fast on disk. Pablo