[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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
