From: | Steve Singer <steve(at)ssinger(dot)info> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tracking commit timestamps |
Date: | 2014-11-10 16:58:12 |
Message-ID: | BLU436-SMTP24871A2AC0110E46A50D126DC800@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-11-10 17:09:08 | Re: Proposal: Log inability to lock pages during vacuum |
Previous Message | Magnus Hagander | 2014-11-10 16:43:44 | Re: SSL information view |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-11-11 16:10:47 | Re: tracking commit timestamps |
Previous Message | Robert Haas | 2014-11-10 13:55:10 | Re: tracking commit timestamps |