Re: B+ versus hash maps

From: Ragnar <gnari(at)hive(dot)is>
To: "surabhi(dot)ahuja" <surabhi(dot)ahuja(at)iiitb(dot)ac(dot)in>
Cc: Jim Nasby <jnasby(at)pervasive(dot)com>, Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: B+ versus hash maps
Date: 2006-06-16 14:52:20
Message-ID: 1150469540.11815.188.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2006-06-16 15:16:29 Re: postgres and ldap
Previous Message Bill Moran 2006-06-16 14:41:34 Re: VACUUMing sometimes increasing database size /