Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id B39942E00A8
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 28 Nov 2007 09:27:27 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 30997-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 28 Nov 2007 09:27:11 -0400 (AST)
Received: from mx00.pub.collaborativefusion.com
	(mx00.pub.collaborativefusion.com [206.210.89.199])
	by postgresql.org (Postfix) with ESMTP id 637E42E0048
	for <pgsql-performance@postgresql.org>;
	Wed, 28 Nov 2007 09:27:18 -0400 (AST)
Received: from vanquish.pitbpa0.priv.collaborativefusion.com
	(vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61])
	(SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wingspan with esmtp; Wed, 28 Nov 2007 08:27:17 -0500
	id 00056414.474D6CB5.00002A97
Date: Wed, 28 Nov 2007 08:27:16 -0500
From: Bill Moran <wmoran@collaborativefusion.com>
To: pgsql-performance@postgresql.org
Subject: Re: TB-sized databases
Message-Id: <20071128082716.91bbad9c.wmoran@collaborativefusion.com>
In-Reply-To: <Pine.LNX.4.58.0711281248290.3731@aragorn.flymine.org>
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>
	<Pine.LNX.4.58.0711281248290.3731@aragorn.flymine.org>
Organization: Collaborative Fusion
X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd6.2)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200711/339
X-Sequence-Number: 27754

In response to Matthew <matthew@flymine.org>:

> On Tue, 27 Nov 2007, Pablo Alcaraz wrote:
> > 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.
> 
> You mean: Be able to tell Postgres "Don't ever do a sequential scan of
> this table. It's silly. I would rather the query failed than have to wait
> for a sequential scan of the entire table."
> 
> Yes, that would be really useful, if you have huge tables in your
> database.

Is there something wrong with:
set enable_seqscan = off
?

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023