On Wed, 28 Nov 2007, Gregory Stark wrote: > > 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. The query planner is not always right. I would like an option like "set enable_seqscan = off" but with the added effect of making Postgres return an error if there is no alternative to scanning the whole table, because I have obviously made a mistake setting up my indexes. I would effectively be telling Postgres "For this table, I *know* that a full table scan is dumb for all of my queries, even if the statistics say otherwise." Of course, it would have to be slightly intelligent, because there are circumstances where a sequential scan doesn't necessarily mean a full table scan (for instance if there is a LIMIT), and where an index scan *does* mean a full table scan (for instance, selecting the whole table and ordering by an indexed field). Matthew -- Existence is a convenient concept to designate all of the files that an executable program can potentially process. -- Fortran77 standard ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend