Re: Weird performance drop after VACUUM

Поиск
Список
Период
Сортировка
От Michael Fuhr
Тема Re: Weird performance drop after VACUUM
Дата
Msg-id 20050827014126.GA33637@winnie.fuhr.org
обсуждение исходный текст
Ответ на Re: Weird performance drop after VACUUM  (asif ali <asif_icrossing@yahoo.com>)
Ответы Re: Weird performance drop after VACUUM  (asif ali <asif_icrossing@yahoo.com>)
Список pgsql-performance
On Fri, Aug 26, 2005 at 05:10:49PM -0700, asif ali wrote:
> "GroupAggregate  (cost=195623.66..206672.52 rows=20132
> width=16) (actual time=8205.283..10139.369 rows=55291
> loops=1)"
> "  ->  Sort  (cost=195623.66..198360.71 rows=1094820
> width=16) (actual time=8205.114..9029.501 rows=863883
> loops=1)"
> "        Sort Key: keyword_id"
> "        ->  Seq Scan on keyword_conversion_table c
> (cost=0.00..29990.83 rows=1094820 width=16) (actual
> time=0.057..1422.319 rows=863883 loops=1)"
> "              Filter: ((conversion_date >=
> '2005-06-07'::date) AND (conversion_date <=
> '2005-08-17'::date))"
> "Total runtime: 14683.617 ms"

What are your effective_cache_size and work_mem (8.x) or sort_mem (7.x)
settings?  How much RAM does the machine have?  If you have enough
memory then raising those variables should result in better plans;
you might also want to experiment with random_page_cost.  Be careful
not to set work_mem/sort_mem too high, though.  See "Run-time
Configuration" in the "Server Run-time Environment" chapter of the
documentation for more information about these variables.

--
Michael Fuhr

В списке pgsql-performance по дате отправления:

Предыдущее
От: asif ali
Дата:
Сообщение: Re: Weird performance drop after VACUUM
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: Limit + group + join