Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 5CF192E02BB for ; Wed, 28 Nov 2007 09:59:42 -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 37701-02 for ; Wed, 28 Nov 2007 09:59:29 -0400 (AST) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id 8B0022E029A for ; Wed, 28 Nov 2007 09:59:37 -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:59:36 -0500 id 00056434.474D7448.00002ED4 Date: Wed, 28 Nov 2007 08:59:35 -0500 From: Bill Moran To: Gregory Stark Cc: pgsql-performance@postgresql.org Subject: Re: TB-sized databases Message-Id: <20071128085935.f2b5e0c5.wmoran@collaborativefusion.com> In-Reply-To: <871waah3ux.fsf@oxford.xeocode.com> 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> <20071128082716.91bbad9c.wmoran@collaborativefusion.com> <871waah3ux.fsf@oxford.xeocode.com> 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/345 X-Sequence-Number: 27760 In response to Gregory Stark : > "Bill Moran" writes: > > > In response to Matthew : > > > >> 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 > > ? > > This does kind of the opposite of what you would actually want here. What you > want is that if you give it a query which would be best satisfied by a > sequential scan it should throw an error since you've obviously made an error > in the query. > > What this does is it forces such a query to use an even *slower* method such > as a large index scan. In cases where there isn't any other method it goes > ahead and does the sequential scan anyways. Ah. I misunderstood the intent of the comment. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023