05.05.2014 19:06, Jim Starkey wrote: > My sole reservation is that there can be information lost when a large > valued 64 integer is converted into a double to generate the index key.
AFAIR, int64 integers are not converted into double, they're compressed using their native format. > My second concern is CPU performance. Index bucket traversal has always > been the single greatest hot spot in the architecture. Arno's jump > table, for example, was a net success by reducing CPU at the expense of > index density. The CPU cost of skip over a (variable length?) > transaction id, determine whether there is a second transaction id, and > is so, skip over the second could easily double or triple the cost of > index lookups. In ODS11 we already have variably-length encoded prefix/length and record number elements of the index node. My old tests showed that it costed us about 20-30% in CPU time. The same for txn ids will surely add even more overhead, but it's unlikely to reach 2x-3x levels. Dmitry ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
