> > I'd be real hesitant to do a wholesale conversion, and even more
> > hesitant to add new system indexes to support indexscans that we
> > have not *proven* to be performance bottlenecks.
>
> Well, how do we know where the critical paths are? Seems adding an
> index is a cheap way to know we have all paths covered. If
> the table is
> not updated, the index is really no overhead except 16k of disk space.
I think the overhead is measurable, and I agree, that adding indexes
only to proven performance critical paths is the way to go.
>
> > It's certainly something worth looking at, since we've identified
> > a couple of places like this that are indeed hotspots. But we need
> > to convince ourselves that other places are also hotspots before
> > we add overhead in hopes of making those places faster.
>
> Are you suggesting that heap scan is faster than index in
> most of these
> cases?
Yes, that is what I would guess.
> How many rows does it take for a heap scan to be
> faster than an
> index scan?
I would say we can seq read at least 256k before the index starts
to perform better.
This brings me to another idea. Why do our indexes need at least
one level ? Why can't we have an index that starts with one leaf page,
and only if that fills up introduce the first level ?
Andreas