On Fri, Nov 19, 2004 at 14:45:04 +0100,
Marc Boucher <pgml@xxxxxxx> wrote:
> At 16:23 18/11/2004 +0100, Martijn van Oosterhout wrote:
> > The system seems to think that a scan is cheap because the table is so
> > small.
> The table currently contains just over 10000 elements. So 238 rows is a
> small part of it.
No, small is typically less than 1%. This depends on the size of the rows
and how much better accessing disk blocks sequentially is in your
enviroment and the size of your cache.
Because your table is so small it will probably all be cached after being
read through once, so you may want to tune your config settings to
say than random disk access costs only a little more than sequential
access. However, you need to be careful if your table is going to grow
a lot larger.
> Since the table is still growing, and the amount of rows in the reply of
> the query is quite uniform (it's not dependant on the size of the table), I
> hope that the statistics will evolve in a state that will force the use of
> the index.
Index scans aren't always faster than sequential scans.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
