> 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 [email protected] End Point Corporation PGP Key: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8
signature.asc
Description: PGP signature
_______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general
