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
|
Список | 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 по дате отправления: