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


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