Search Postgresql Archives

Re: Postgresql 9.0.6 alway run VACUUM ANALYZE pg_catalog.pg_attribute

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux