"Decibel!" <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers