Re: Sequencial scan instead of using index - Mailing list pgsql-performance

From Harry Hehl
Subject Re: Sequencial scan instead of using index
Date
Msg-id 6AD4F3A63B017C4FB074E2C895AD18541090FB@EXCHSRV.waterloonetworking.net
Whole thread Raw
In response to Sequencial scan instead of using index  ("Harry Hehl" <Harry.Hehl@diskstream.com>)
List 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




pgsql-performance by date:

Previous
From: Markus Schaber
Date:
Subject: Re: Better index stategy for many fields with few values
Next
From: Markus Schaber
Date:
Subject: Re: FOREIGN KEYS vs PERFORMANCE