Re: tracking commit timestamps

On 11/10/2014 08:39 AM, Petr Jelinek wrote:
> On 09/11/14 17:57, Steve Singer wrote:
>> On 11/07/2014 07:07 PM, Petr Jelinek wrote:
>>> The list of what is useful might be long, but we can't have everything
>>> there as there are space constraints, and LSN is another 8 bytes and I
>>> still want to have some bytes for storing the "origin" or whatever you
>>> want to call it there, as that's the one I personally have biggest
>>> use-case for.
>>> So this would be ~24bytes per txid already, hmm I wonder if we can
>>> pull some tricks to lower that a bit.
>>>
>>
>> The reason why Jim and myself are asking for the LSN and not just the
>> timestamp is that I want to be able to order the transactions. Jim
>> pointed out earlier in the thread that just ordering on timestamp allows
>> for multiple transactions with the same timestamp.
>>
>> Maybe we don't need the entire LSN to solve that.  If you already have
>> the commit timestamp maybe you only need another byte or two of
>> granularity to order transactions that are within the same microsecond.
>>
>
> Hmm maybe just one part of LSN, but I don't really like that either, 
> if we want to store LSN we should probably store it as is as somebody 
> might want to map it to txid for other reasons.
>
> I did the calculation above wrong btw, it's actually 20 bytes not 24 
> bytes per record, I am inclined to just say we can live with that.
>
> Since we agreed that the (B) case is not really feasible and we are 
> doing the (C), I also wonder if extradata should be renamed to nodeid 
> (even if it's not used at this point as nodeid). And then there is 
> question about the size of it, since the nodeid itself can live with 2 
> bytes probably ("64k of nodes ought to be enough for everybody" ;) ).
> Or leave the extradata as is but use as reserved space for future use 
> and not expose it at this time on SQL level at all?
>
> I guess Andres could answer what suits him better here.
>

I am happy with renaming extradata to nodeid and not exposing it at this 
time.

If we feel that commit-order (ie LSN or something equivalent) is really 
a different patch/feature than commit-timestamp then I am okay with that 
also but we should make sure to warn users of the commit-timestamp in 
the documentation that two transactions might have the same timestamp 
and that the commit order might not be the same as ordering by the 
commit timestamp.