>
> > Assuming it only does "prefix" and not "segment", then I don't think
> this will help because the DOCID for each key in JSON_PATH will be
> different, making the "prefix" to each path across different documents
> distinct.
>
> I’m not sure I follow you here, or we have different understandings of the
> proposal. When I’m reading a document in this model I’m retrieving a set of
> keys that all share the same {DOCID}. Moreover, if I’ve got e.g. an array
> sitting in some deeply nested part of the document, the entire path
> doc.foo.bar.baz.myarray is common to every element of the array, so it’s
> actually quite a nice case for elision.
>Doh! I was focusing on somehow doing something about the same "foo/bar/baz" in thousands of different documents, rather than nested maps/arrays in the same document. My biggest hurdle on the keys isn't the 10k limit, I think that's a perfectly reasonable restriction. It's all the storage duplication requirement for the repeated key "strings" assuming document values are being stored independently in the DB (which I'm inclined to think is overall more useful than a "whole document" storage approach). Especially for really long arrays. If FDB can in fact eliminate most of this storage duplication cost, then why bother with a key mapping translation at all? As I don't see the 10k limitation as having significant merit, the only purposes I can see are: 1) to get keys down under/equal to the 32 bytes optimization level. Probably four or five, 6/8 byte segments. 2) reduce network transfer bandwidth requirements. ----------- But regardless, if FDB can optimize out the duplicate storage cost for key prefixes like you describe, then keep it simple and skip the key translator. Cheers! Mike
