Skip site navigation (1) Skip section navigation (2)

Re: TB-sized databases

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: TB-sized databases
Date: 2007-11-28 13:59:35
Message-ID: 20071128085935.f2b5e0c5.wmoran@collaborativefusion.com (view raw or flat)
Thread:
Lists: pgsql-performance
In response to Gregory Stark <stark(at)enterprisedb(dot)com>:

> "Bill Moran" <wmoran(at)collaborativefusion(dot)com> writes:
> 
> > In response to Matthew <matthew(at)flymine(dot)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
> > ?
> 
> 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(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

In response to

pgsql-performance by date

Next:From: Csaba NagyDate: 2007-11-28 14:03:44
Subject: Re: TB-sized databases
Previous:From: Gregory StarkDate: 2007-11-28 13:55:02
Subject: Re: TB-sized databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group