[Please don't top-post. http://www.idallen.com/topposting.html ]
tuanhoanganh wrote:
> Kevin Grittner > tuanhoanganh wrote:
>>> VACUUM ANALYZE pg_catalog.pg_attribute, pg_catalog.pg_type,
>>> pg_catalog.pg_depend run all time of day.
>> What are the results of running the query on this page?:
>>
>> http://wiki.postgresql.org/wiki/Server_Configuration
> Here is my config
> "version";"PostgreSQL 9.0.6, compiled by Visual C++ build 1500,
> 64-bit"
If you can, an update would be good.
http://www.postgresql.org/support/versioning/
That said, I don't see any particular bug fixes that would be
related.
> "autovacuum_analyze_threshold";"250"
> "autovacuum_vacuum_threshold";"1000"
My experience is that setting these smaller helps autovacuum keep
small tables from bloating, reducing the overall work done by
autovacuum and improving overall performance. This *might* be a
contributing factor to you issue.
> "enable_seqscan";"off"
This is a very bad idea. A seqscan if often the fastest way to get
a set of data. If seqscans where being chosen when some other
technique actually was faster, you probably have a heavily cached
active data set, and would do much better to turn this back on and
set:
seq_page_cost = 0.1
random_page_cost = 0.1
cpu_tuple_cost = 0.03
I have found these settings to work well with my data and workloads,
you may need to make adjustments to find the best settings for your
environment.
Again, this doesn't seem related to your question, but if you are
cncerned about performance, it should help.
> "shared_buffers";"2GB"
Benchmarks have shown that 16MB generally helps performance.
>> How is overall performance on the machine?
It would help to know whether the autovacuum processes you are seeing
are actually using a lot of CPU or disk IO. Do they reappear after a
restart? Are these processes involved in any blocking (ni sp_locks)?
-Kevin