Tom,
> If you're using autovacuum then the problem is already taken care of.
> It will be taken care of better in 8.2, if we add per-table tracking
> of XID wraparound risk, but it's handled now. The only way that this
> proposal makes any sense is if you are trying not to vacuum at all, ever.
Hmmm ... the potential problem which Simon is mentioning is very real ... in
large DWs, there may be tables/partitions which are never, ever vacuumed.
Ever.
For example, at one client's site they load their data via ETL jobs that
insert about 25 million rows a day and update about 100,000. Given that
updates are < 5%, there is no reason from a data efficiency perspective to
ever vacuum. So that's the plan ... the main fact table will never, ever
be vacuumed. (in that particular case, since the ETL uses large transaction
batches, XID wraparound won't happen for about 20 years. But with a
different data load model, it could be a serious problem).
So, will per-table XID tracking allow us to avoid *ever* vacuuming some
tables? If not, what could?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
