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 >
