Re: XID wraparound in 8.4

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

 



Reason we dont turn on autovacuum is that we are a "high-volume"
insert shop with minimal updates..We have about 200 million inserts
and a few thousand updates only. Most tables are partitions and get
dropped as part of the purge. Hence..autovacuum is a waste of
resources. However...the XID issue will force the need for an
autovacuum at some point..hence we do it as a one-off occasionally.

2009/8/11 Scott Marlowe <scott.marlowe@xxxxxxxxx>:
> 2009/8/11 Anj Adu <fotographs@xxxxxxxxx>:
>> So..we dont have to check the last XID value per table ?
>>
>> we have a very high volume data warehouse for which autovacuum is not
>> suitable due to performance reasons. Can we track the last XID on a
>> per-table basis ?
>
> autovacuum is highly tunable so as to remove the burden of running it
> and having it suck up all your IO mid day.  Are you saying that no
> amount of autovacuum tuning can fix the overhead issues of autovac, or
> that you've just decided not to use it on principle?
>
> Assuming you do the load at night, vacuum after load, no updates
> during the day, I can totally see just turning off autovacuum, but
> sometimes it nice to leave it on set to some very low load (i.e.
> autovacuum_vacuum_cost_delay=20ms) so that should you forget about
> some table, you won't get caught out by table bloat but also won't
> have autovacuum killing IO midday.
>
> Just a thought.
>
> Either way, autovacuum WILL kick in if it has to to fix a wrap around
> issue even if it's turned off.
>

-- 
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux