Re: [Fwd: Re: [PATCHES] 64-bit CommandIds]

"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...