> At least in our DocumentStoreImplementations (Mongo and RDB), making the > UUID something indexed by the storage (so either Mongo or the relational > database) should be relatively cheap (after all, the UUID never changes once > assigned, right?). That would eliminate the indexing overhead in Oak itself > completely.
That'd just shift the storage from collection/table to index/rdb_index. At least mongo tries to keep its indices in memory, so the memory overhead would probably remain similar (well, in terms of order of magnitude at least). I think avoiding un-necessary uuid and optimizing uuid index are 2 separate problems. Chetan and Thomas, afaics, are discussing the former. Thanks, Vikas
