Re: Sequencial scan instead of using index

["Harry Hehl" <Harry(dot)Hehl(at)diskstream(dot)com>]

Thanks Mark, 

>Hmm - that first query needs to do a sort, so you might want to
experiment with the sort_mem parameter. Could you show us output from
explain analyze for >both the above queries?

Not too concerned about the sort, more about the query performance with
seq scan as the tables size increases.

>At face value, selecting 200000 rows (assuming the estimates are
accurate) may mean that a seqscan is the best plan! But we'll know more
after seeing the >explain analyze...

200000 rows is about right.  

I saw Tom's response on the planner improvement in 8.2 but I was still
going to send the explain analyze output.
However I can't show you explain analyze. The postmaster goes to 99% cpu
and stays there. The explain analyze command hangs...

It is starting to look like inheritance does help in modeling the data,
but for searches parallel flat tables that don't use inheritance is
required to get optimum query performance. 

Has anyone else come to this conclusion?

Thanks