Common memcmp'rable index format is probably the best sweet spot of Falcon I
can think of, from developers point of view.
Considering binary representation while doing sort/search/key compression
was a big pain in the back for me at the time I have done it for various
archaic Adabas datatypes (alphanumeric ASCII and EBCDIC , binary integer
types in big and little endian , Unicode(UTF8), packed, unpacked and fixed
decimal, IEEE float and double)
I think I would not map all numbers to double though if I'd be doing that
from scratch ;) , it is a strange imprecise format.
> -----Original Message-----
> From: falcon-return-308-wlad=sun.com@stripped [mailto:falcon-
> return-308-wlad=sun.com@stripped] On Behalf Of Jim Starkey
> Sent: Monday, December 15, 2008 5:28 PM
> To: FalconDev
> Subject: Falcon Index Keys
>
> Falcon index keys are designed to compare naturally byte-wise so that
> index code doesn't need to worry about data types, multi-segment keys,
> and collation sequences. The theory is that index processing involves
> a
> lot of comparisons, and making the comparisons as cheap as possible is
> the best strategy. Collations and multi-segment handling both fluffy
> up
> the index, possibly to the extent that the strategy needs to be
> reviewed.
>
> An alternative I've used in Nimbus is to use EncodedDataStreams to
> encode index keys. It requires more processing per comparison but the
> keys, particularly multi-segment keys, are smaller. Prefix compression
> isn't as nice (but isn't an issue in Nimbus), which is a significant
> consideration.
>
> I'm not recommending that Falcon change key formats, particularly for
> this version. But the issue is well worth periodic reconsideration.
>
> --
> Jim Starkey
> President, NimbusDB, Inc.
> 978 526-1376
>
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
