>> Please show us the output from running this query:
>>
>> http://wiki.postgresql.org/wiki/Server_Configuration
> [very reasonable settings except for a very large work_mem]
> Make sure that work_mem setting isn't driving you into swapping or
> near-zero caching. A shortage of cache space could
Baptiste LHOSTE wrote:
>> Please show us the output from running this query:
>>
>> http://wiki.postgresql.org/wiki/Server_Configuration
> [very reasonable settings except for a very large work_mem]
Make sure that work_mem setting isn't driving you into swapping or
near-zero caching. A shortage
Hi,
> That depends on configuration settings and on whether the computer
> (or VM) is so swamped that the autovacuum task is starved for cycles.
> Also on any overrides of statistics targets for those tables.
> Please show us the output from running this query:
> http://wiki.postgresql.org/wiki/
Baptiste LHOSTE wrote:
> Today I consulted the log of my PostgreSQL server and I saw that
> autovacuum tasks took to much time to do their work. I thought that
> ANALYZE was a fast operation ?
That depends on configuration settings and on whether the computer
(or VM) is so swamped that the autova
Hi,
Today I consulted the log of my PostgreSQL server and I saw that autovacuum
tasks took to much time to do their work. I thought that ANALYZE was a fast
operation ?
2012-11-09 10:52:33 CET LOG: automatic analyze of table
"flows.public.agg_t20_outgoing_a41_src_net_and_dst_net_f5" system usa
Hi,
> So that an auto-ANALYZE should run each 2.5-3 hours.
>
> If it does not proceed, check that you do not have some process still doing
> manual maintenance or DDL on those tables, they might
> lock the table and kill autovacuum
>
> (check the pg_stat_activity, and set log_autovacuum_min_du
> relname | last_autoanalyse | reltuples | relpages |
> n_tup_ins + n_tup_upd + n_tup_del
>
> | (from pg_stat_all_tables) | | | (from
> | pg_stat_all_tables)
>
> table1 | 2012-10-15 21:12:04.362647+02 | 2.53296e+06 |50789 | 28542483
> t
Hi,
> in pg_stat_user_tables, not since the last time ANALYZE run, but you have the
> number of reltuples from pg_class that is used to calculate the ratio.
So how does the autovacuum daemon to determine the number of obsolete row since
its last work on a specific table ?
> Everything is relat
Hi,
> second one on which we insert some new data every five minutes (avg~200
> rows) and delete old data about every 1 hour (avg~1000 rows). For complete
> understanding, we need up-to-date stats for the second one because the
> recurrent deletion might take a long time, (~1mn for less than 1000
