Re: Sequencial scan instead of using index

Поиск
Список
Период
Сортировка
От Harry Hehl
Тема Re: Sequencial scan instead of using index
Дата
Msg-id 6AD4F3A63B017C4FB074E2C895AD18541090FB@EXCHSRV.waterloonetworking.net
обсуждение исходный текст
Ответ на Sequencial scan instead of using index  ("Harry Hehl" <Harry.Hehl@diskstream.com>)
Список 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 по дате отправления:

Предыдущее
От: Markus Schaber
Дата:
Сообщение: Re: Better index stategy for many fields with few values
Следующее
От: Markus Schaber
Дата:
Сообщение: Re: FOREIGN KEYS vs PERFORMANCE