From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Minimally avoiding Transaction Wraparound in VLDBs |
Date: | 2005-09-01 04:22:19 |
Message-ID: | 200508312122.19664.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2005-09-01 04:34:25 | broken configure, broken makefile? |
Previous Message | Andrew - Supernews | 2005-09-01 04:21:58 | Re: Minimally avoiding Transaction Wraparound in VLDBs |