[Bucardo-general] Design of new txntime field

[Greg Sabino Mullane]

> If we're going for space savings, it'd be just as well to leave out the
> unnecessary dots, wouldn't it? It's still pretty easily readable without
> them if you know what and how wide the fields are.

Yeah, perhaps so, but I'm hesitant to go down that path too far (see below).

> We could use the same approach with txnid_current() and keep only the last
> few digits, right? That would be a lot more consistent across OSes than PID
> allocations are.

Hmm...good point. Probably no better or worse than PIDs as far as collission 
chances. txid_current() claims it generates the txid if there is not one 
already, but does that make it more expensive than pg_backend_pid? My guess 
is it doesn't matter.

> It could probably be converted to 1 or 2 bigints, which would more
> efficiently use the space available, and sort more quickly, at the cost of
> no easy readability of the source inputs.

Yep, I've toyed with the idea of throwing away all human readability and 
just documenting things well, in order to save space. At the end of the 
day, the txntimes are rarely used for anything other than grouping, and 
it may be better to save the space, which becomes an important issue 
on large installations.

Thus begins the game of Perl^H^H^H^H database golf - how small could we 
make this field? We can probably assume that nobody is going to mess 
with the timestamps on their database, so it's safe to say everything 
will be > 2000 A.D. and < 3000 A.D. (at which point Perl 6 will finally 
be officialy completed). Even without the added precision from pid/txid, 
'epoch' will not fit into an int a little over 20 years from now. :) So, a 
single bigint it is, unless we modify the timestamp (which is not 
too wild an idea - we only need a relative timestamp, after all, to do the 
conflict handling).

...checks....

Hmmm, there are some Bucardo installations in the wilde with some *really* big 
delta tables, so I'm leaning towards smaller is better. Going to mull this over. 
Feel free to jump in anyone, esepcially if you manually eyeball the 
txntime field now for any reason.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 2529 DF6A B8F7 9407 E944  45B4 BC9B 9067 1496 4AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20170911/057ddd8c/attachment.sig>