On fös, 2006-06-16 at 11:39 +0530, surabhi.ahuja wrote:
[in response to Jim advising not to set random_page_cost=1]
> in that case, should i set
> enable_seqscan parameter to off at the time of starting postmaster?
that is unlikely to be a good stategy.
> because i have seen that even thou the index exists it still goes for
> seq scan
there can be many situations where a sequential scan
is the correct thing to do.
it is not clear whether you have a case that needs
to be optimized, or if you are just assuming that
a sequential scan must is wrong.
things that may be causing wrong choice of seqscan include:
table has not been ANALYZED lately
some columns need higer statistics target
table contain few rows
table is not correctly indexed
search using non-indexable operators
query phrased in a way that prevents use of indexes
so before jumping to setting wild global settings, you
should make sure you understand what your problem really
is.
the best way to do that is by looking at the output of
EXPLAIN ANALYZE.
show us the output of EXPLAIN ANALYZE <yourquery>, along
with details about relevant columns, indexes, so that we
can give more concrete advice.
gnari
>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
