On Mon, Feb 28, 2005 at 16:46:34 +0100,
Markus Schaber <[EMAIL PROTECTED]> wrote:
> Hi, Matthew,
>
> Matthew T. O'Connor schrieb:
>
> > The version of pg_autovacuum that I submitted for 8.0 could be
> > instructed "per table" but it didn't make the cut. Aside from moved out
> > of contrib and
Gaetano Mendola wrote:
Yes, I'm aware about it indeed I need the analyze because usualy I do on that
table select regarding last 24 ours so need to analyze it in order to
collect the statistics for this period.
Beside that I tried to partition that table, I used both tecnique on
my knowledge
1) A
Hi, Matthew,
Matthew T. O'Connor schrieb:
> The version of pg_autovacuum that I submitted for 8.0 could be
> instructed "per table" but it didn't make the cut. Aside from moved out
> of contrib and integrated into the backend, per table autovacuum
> settings is probably the next highest priority
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schaber wrote:
> Hi, Gaetano,
>
> Gaetano Mendola schrieb:
>
>
>>I have the same requirement too. Actually pg_autovacuum can not be
>>instructed "per table" so some time the global settings are not good
>>enough. I have a table of logs with 6
Hi, Gaetano,
Gaetano Mendola schrieb:
> Yes, I'm aware about it indeed I need the analyze because usualy I do on that
> table select regarding last 24 ours so need to analyze it in order to
> collect the statistics for this period.
If you tend to do lots of queries for the last 24 hours, and th
Hi, Gaetano,
Gaetano Mendola schrieb:
> I have the same requirement too. Actually pg_autovacuum can not be
> instructed "per table" so some time the global settings are not good
> enough. I have a table of logs with 6 milions rows ( 3 years logs )
> I insert on that page ~ 6000 rows for day. I'm
Matthew T. O'Connor wrote:
> Christopher Browne wrote:
>
>> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>>
>>
>>> I do a graph about my disk usage and it's a ramp since one week,
>>> I'll continue to wait in order to see if it will decrease.
>>> I was expecting the steady state at something like
Christopher Browne wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
I do a graph about my disk usage and it's a ramp since one week,
I'll continue to wait in order to see if it will decrease.
I was expecting the steady state at something like 4 GB
( after a full vacuum and reindex ) + 10 % = 4
Christopher Browne wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>
>
>>Tom Lane wrote:
>>
>>>Gaetano Mendola <[EMAIL PROTECTED]> writes:
>>>
>>>
I'm using ony pg_autovacuum. I expect that disk usage will reach
a steady state but is not. PG engine: 7.4.5
>>>
>>>
>>>One data point do
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Matthew T. O'Connor wrote:
>
>> Well without thinking too much, I would first ask about your FSM
>> settings? If they aren't big enought that will cause bloat. Try
>> bumping your FSM settings and then see if you reach steady state.
>
> FSM settings a
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>>
>>>I'm using ony pg_autovacuum. I expect that disk usage will reach
>>>a steady state but is not. PG engine: 7.4.5
>>
>>
>> One data point doesn't prove that you're not at a steady st
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>
>>I'm using ony pg_autovacuum. I expect that disk usage will reach
>>a steady state but is not. PG engine: 7.4.5
>
>
> One data point doesn't prove that you're not at a steady state.
I do a graph about my disk usage and it's a ramp
Matthew T. O'Connor wrote:
> Well without thinking too much, I would first ask about your FSM
> settings? If they aren't big enought that will cause bloat. Try
> bumping your FSM settings and then see if you reach steady state.
FSM settings are big enough:
max_fsm_pages | 200
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> I'm using ony pg_autovacuum. I expect that disk usage will reach
> a steady state but is not. PG engine: 7.4.5
One data point doesn't prove that you're not at a steady state.
> # vacuum full verbose messages;
> INFO: vacuuming "public.messages"
> INF
Gaetano Mendola wrote:
pg_class after the vacuum full for that table
relfilenode | relname | relpages | reltuples
-+--+--+-
18376 | messages |63307 | 1.60644e+06
pg_class before the vacuum full for that table
relfilenode | relname | relpages | r
Hi all,
I'm running since one week without use any vacuum full,
I'm using ony pg_autovacuum. I expect that disk usage will reach
a steady state but is not. PG engine: 7.4.5
Example:
The message table is touched by pg_autvacuum at least 2 time a day:
$ cat pg_autovacuum.log | grep VACUUM | grep
16 matches
Mail list logo
