From: | Scott Mead <scott(dot)lists(at)enterprisedb(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, Krzysztof Kardas <krzychk2(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL with Zabbix - problem of newbe |
Date: | 2010-04-09 15:13:39 |
Message-ID: | i2od3ab2ec81004090813nc6411715k15b54b46e28c5219@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
The OP is using:
autovacuum_vacuum_threshold | 100000
That means that vacuum won't consider a table to be 'vacuum-able' until
after 100k changes.... that's nowhere near aggressive enough. Probably
what's happening is that when autovacuum finally DOES start on a table, it
just takes forever.
--Scott
2010/4/9 Merlin Moncure <mmoncure(at)gmail(dot)com>
> 2010/4/9 Greg Smith <greg(at)2ndquadrant(dot)com>:
> > Merlin Moncure wrote:
> >>
> >> postgresql 8.2: autovacuum enabled by default
> >> postgresql 8.3: HOT (reduces update penalty -- zabbix does a lot of
> >> updates)
> >>
> >
> > autovacuum wasn't enabled by default until 8.3. It didn't really work
> all
> > that well out of the box until the support for multiple workers was added
> in
> > that version, along with some tweaking to its default parameters.
> There's
> > also a lot more logging information available, both the server logs and
> the
> > statistics tables, to watch what it's doing that were added in 8.3.
>
> you're right! iirc it was changed at the last minute...
>
> merlin
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-04-09 15:27:54 | Re: 3ware vs. MegaRAID |
Previous Message | Merlin Moncure | 2010-04-09 15:06:07 | Re: PostgreSQL with Zabbix - problem of newbe |