Hi all, i've read many comments on this argument, but seems that ideas to solve this problem (if it is a true real problem in near future) are not many.
I remember that in 8086 era, when addressable memory became cheaper and bigger than dimension reserved in opcode space (24 bits IIRC), hardware architecture changed a bit, implementing relocation tables, where low level bits where the displacement in a page and higher bits instead where used as a pointer in a page table containing the base address of the real memory page. As a parallel in our case, not many transaction IDs are important, interesting or whatever you want call them, between 0 and next transaction number, a lot of them could be ... "forgotten". I know that transaction management is not implemented in hardware, but having this in memory could help and shouldn't be very big in size. AFAIU many classes uses transaction information and probably transaction ID relocation algebra should be overloaded in the transaction class (don't know if are there any such class, it's completely a hypothetical reasoning). With a management like this, are any chance to re-compact them? If a page of "relocatable IDs" has no more "pending" transaction, should be discarded and the next can downgrade to occupy the freed "address space": this maybe needs a use count, with the good and the bad it has. Anyway, as are they are implemented now, it's not a simple task, because, and maybe here i'm very wrong, they are used for different purposes: mark different versions of a record as they are created AND time ordering any correlated on unrelated change in DDL or DML of the database (AND maybe other things I don't remember now or I'm not aware). Perhaps discussion about this should be better in fb-architect, but searching "transaction id" I found other type of philosophical discussion there. And in tracker.. nothing at all? A note should be somewhere, but cannot find it right now. Comments? Ciao. Mimmo. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel