"Decibel!" <decibel@decibel.org> writes:
> If we're going to make this a ./configure option, ISTM we should do the same
> with XID size as well. I know there are high-velocity databases that could use
> that.
Keep in mind we just changed things so that read-only transactions don't
consume xids. That means you would have to be actually modifying 2-billion
records before wrap-around becomes an issue.
If you're modifying 2-billion records that quickly presumably you're going to
have other pressing reasons to run vacuum aside from xid freezing...
Also, consider that you're suggesting increasing the per-tuple overhead from
24 bytes to, if my arithmetic is right, 40 bytes.
So really you would need, say, a system with enough i/o bandwidth to handle
2-billion updates or inserts per day and with enough spare i/o bandwidth that
another 16-bytes on every one of those updates is ok, but without the ability
to run vacuum.
Also, we still have hope that the visibility map info will make running vacuum
even less of an imposition.
All that said I don't really see much reason not to make it an option. I just
don't think anyone really needs it. In 5-10 years though...
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!