Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 4616F2E3410 for ; Wed, 28 Nov 2007 09:55:14 -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 36375-04-5 for ; Wed, 28 Nov 2007 09:55:01 -0400 (AST) Received: from oxford.xeocode.com (unknown [62.232.55.118]) by postgresql.org (Postfix) with ESMTP id 24B772E357B for ; Wed, 28 Nov 2007 09:55:09 -0400 (AST) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.67) (envelope-from ) id 1IxNNW-0001Nv-Ic; Wed, 28 Nov 2007 13:55:02 +0000 To: "Bill Moran" Cc: Subject: Re: TB-sized databases In-Reply-To: <20071128082716.91bbad9c.wmoran@collaborativefusion.com> (Bill Moran's message of "Wed\, 28 Nov 2007 08\:27\:16 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX.performance" 3365) 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> From: Gregory Stark Organization: EnterpriseDB Date: Wed, 28 Nov 2007 13:55:02 +0000 Message-ID: <871waah3ux.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/343 X-Sequence-Number: 27758 "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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!