From 587cbd3fe15fd879b4daf67ecf4e90740d3da8dd Mon Sep 17 00:00:00 2001 From: Rob Austin Date: Tue, 23 Dec 2014 09:59:44 +0000 Subject: [PATCH] HCOLL-197 reworeded Oversized Entries Support --- README.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index aa0f414c1..2821ae458 100644 --- a/README.md +++ b/README.md @@ -601,13 +601,15 @@ If after some business logic, in our example after reading the 'issueDate' and ## Oversized Entries Support -It is possible for the size of your entry to be 64 times as large as the maximum entry size, -we refer to this type of entry as an oversized entry. Oversized entries are there to cater for the case -where only a small -percentage of your entries are larger than the others, in this case your large entry will -span across a number of entries. The alternative would be to increase your maximum entry size to be similar +It is possible for the size of your entry to be larger than the space which chronicle map +internally allocates to each entry. We refer to this type of entry as an oversized entry. +Oversized entries are there to cater for the case +where only a small percentage of your entries are larger than the others, in this case your large entry will +span across a number of entries. The alternative would be to increase the internal entry size to be similar to the size of the largest entry, but this approach is wasteful of memory, especially when most -entries are no where near the max entry size. +entries are no where near the max entry size. So put simply Chronicle map is able to accept entries +where each can have a different size but it does this in a way that is not wasteful of space. + ## Serialization