"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...
Doing this for XIDs is pretty useless this days.
It is only targeted for command ids which are consumed heavily by
stored procedure languages.
It happens once on a while that a complex business logic procedure
runs out of command ids inside a transaction.
the idea is to give users a chance to avoid that.
touching XIDs does not make sense to me at all.
many thanks,
hans
--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at