So far, these are the suggestions I've seen (I'm adding my own suggestion at the bottom):
1. Implement 64 bit id:s and use them everywhere always. Pros: - Straightforward once all code has been changed to use 64 bit id:s. - No overhead for various special flags and stuff. Cons: - Will increase disk space even for DB:s that don't need 64 bit id:s. 2. Implement 64 bit id:s but use them only in records where required. use a per-record flag to indicate if the transaction id i 32 bit or 64 bit. Pros: - Will not increase disk space for DB:s that don't need 64 bit id:s. - For DB:s that do need 64 bit id:s, only records with high transaction id:s will take up the additional 4 bytes of space. Cons: - More complicated implementation than suggestion 1. - Runtime overhead for flag checking on each record access. 3. Stay at 32 bit id:s but somehow "compact" all id:s older than OIT(?) into OIT-1. Allow id:s to wrap around. Pros: - No extra disk space. - Probably rather simple code changes for id usage. Cons: - May be difficult to find an effective way to compact old id:s. - Even if an effective way to compact old id:s is found, it may be complicated to implement. - May be difficult or impossible to perform compacting without large amounts of write locks. - Potential for problems if OIT isn't incremented (but such OIT problems should be solved anyway). May I suggest a fourth option? 4. Add a DB wide flag, like page size, indicating if this DB uses 32 bit or 64 bit id:s. Could be changed via backup restore cycle. Pros: - Almost as simple as suggestion 1 once all code has been changed to support 64 bit id:s. - Minimal overhad for flag checking. - DB:s that don't need 64 bit id:s won't need to waste disk space on 64 bit id:s. Cons: - A DB that has been configured with the incorrect flag has to be backed up + restored to change the flag, causing (a one-time) down time. - A bit more complicated to implement and maintain than suggestion 1. Questions: Q1. Will it be extremely difficult to change all code to support 64 bit id:s? So difficult that option 3 is worth investigating thoroughly? As far as I can see, that's the only option to avoid 64 bit id:s. Q2. If support for 64 bit id:s is implemented, how important is it to conserve disk space in cases where 64 bit id:s are not required? And is it important to conserve disk space per record (suggestion 2) or is it sufficient to conserve disk space only for databases where 32 bit id:s suffice (suggestion 4)? Q3. For suggestion 4: the flag has to be "loaded" only on connect, but in the 32 bit case I would assume each record access would cast the loaded 32 bit id to 64 bit. Would the overhead for that logic and cast be noticable and large enough to be problem? I assume the overhead would be less that the per record flag as per suggestion 2, but... maybe not? If suggestion 2 logic is comparable in code complexity and runtime overhead to that of suggestion 4, then I see no reason to go for suggestion 4. Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@datadia.se Telefon: 08-761 06 55 Mobil: 0733-44 24 64 ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
