Re: About b-tree usage

let me, i have turned enable_seqscan to off, in order to discourage
optimizer to choose seq_scan whenever an idex_scan can be used.

But in this case, why optimizer don't chooses seq_scan (discourage is
different than prevent) ?

At many cases i need only a small fragment of raws to be retrieved. But
this extreme case is a real-scenario (not the most frequent but real).

I try to find a way to achieve good performence even for the extreme
case. Is there any way?

ps. In bibliografy, there is a different alternative for indices. except
th simple approach of <attr_val, rid> is the alternative <attr_val, set
of rids>. The second means the attaches to each discrete attr_val the set
o rid's of all raws with same attr_val. Is this alternative taken into
account in postgres?

On Mon, 7 Mar 2005, Jeff Davis wrote:

>
> In that case, sequential scan is faster, but perhaps the planner doesn't
> know that ahead of time. Try turning on more statistics if you haven't
> already, and then run ANALYZE again. If the planner sees a range,
> perhaps it assumes that it is a highly selective range, when in fact, it
> consists of all of the tuples. Also, make sure enable_seqscan is true
> (in case you turned it off for testing or something and forgot).
>
> A seqscan is usually faster when a large proportion of the tuples are
> returned because:
> (1) It uses sequential I/O; whereas an index might access tuples in a
> random order.
> (2) It doesn't have to read the index's disk pages at all.
>
> I suspect you don't need to return all the tuples in the table. If you
> include the details of a real scenario perhaps the people on the list
> could be more helpful.
>