Subject: Re: TB-sized databases
From: Simon Riggs <simon@2ndquadrant.com>
To: Pablo Alcaraz <pabloa@laotraesquina.com.ar>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
In-Reply-To: <474CA2FA.2020201@laotraesquina.com.ar>
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
	<474B1407.3090607@laotraesquina.com.ar> <474B1B8C.1030505@gmail.com>
	<4544e0330711271218h56ce4cc3p280a9fefff24583d@mail.gmail.com>
	<1196197045.4246.1154.camel@ebony.site>
	<474CA2FA.2020201@laotraesquina.com.ar>
Content-Type: text/plain
Date: Wed, 28 Nov 2007 17:28:28 +0000
Message-Id: <1196270908.4246.1250.camel@ebony.site>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2007-11-27 at 18:06 -0500, Pablo Alcaraz wrote:
> 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.

OK, I agree with this one. 

I'd thought that index-only plans were only for OLTP, but now I see they
can also make a big difference with DW queries. So I'm very interested
in this area now.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com