Re: Sequencial scan instead of using index

From: "Harry Hehl" <Harry(dot)Hehl(at)diskstream(dot)com>
To: <markir(at)paradise(dot)net(dot)nz>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Sequencial scan instead of using index
Date: 2006-04-12 13:04:28
Message-ID: 6AD4F3A63B017C4FB074E2C895AD18541090FB@EXCHSRV.waterloonetworking.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

Browse pgsql-performance by date

  From Date Subject
Next Message Markus Schaber 2006-04-12 13:18:55 Re: FOREIGN KEYS vs PERFORMANCE
Previous Message Markus Schaber 2006-04-12 12:59:32 Re: Better index stategy for many fields with few values