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

>
> "Decibel!" <decibel(at)decibel(dot)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...
>

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