On Tuesday 14 August 2001 02:25, you wrote:
> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
> Aside from portability and performance issues, allowing pg_log to grow
> without bound just isn't gonna do. So, the name of the game is to recycle
But what about all of us who need to establish a true long term audit trail?
For us, still the most elegant solution would be a quasi unlimited supply of
unique row identifiers. 64 bit would be a huge help (and will be ubiquitous
in a few years time anyway).
Everything else will have far greater performance impact for us. While it
might not suit everybody, I can't see why it should be a problem to offer
this as an *option*
There are other applications where we need database wide unique row
identifiers; in our project for example we allow row level encryption on
non-indexed attributes across alll tables. How would you implement such a
thing without having unique row identifiers across your whole database? You
would need to reference both to row AND table, and that must certainly be
more expensive in terms of performance.
Horst
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
