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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
