Just thinking loud - would the API be more friendly/simple API if
maxBufDocs/Dels limits to coexist with maxBytes limit?
They seem to serve two different purposes:
- setRAMBufferSizeMB controls memory: "how much memory can be used".
- setMaxBufferedDeleteTerms and setMaxBufferedDocs control freshness: "how
many index modifications are too many to stale".
If a third setMaxStaleDelay(millis) was added it would fall into the second
group of course: "freshness".
On one hand this can always be done by the application.
On the other, the logic of "use memory-limit unless added-docs-limit was
specified" seems somewhat confusing (why only by pending adds, why not also
by pending deletions?). In addition, I saw the old use of maxBufferredDocs
for controlling memory as a compromise. Now that setRAMBufferSizeMB is
available, applications can benefit from both.
(Perhaps the reason is that this would somehow break a merge behavior in a
way that I do not understand?)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
maxBufDocs/Dels limits to coexist with maxBytes limit?
They seem to serve two different purposes:
- setRAMBufferSizeMB controls memory: "how much memory can be used".
- setMaxBufferedDeleteTerms and setMaxBufferedDocs control freshness: "how
many index modifications are too many to stale".
If a third setMaxStaleDelay(millis) was added it would fall into the second
group of course: "freshness".
On one hand this can always be done by the application.
On the other, the logic of "use memory-limit unless added-docs-limit was
specified" seems somewhat confusing (why only by pending adds, why not also
by pending deletions?). In addition, I saw the old use of maxBufferredDocs
for controlling memory as a compromise. Now that setRAMBufferSizeMB is
available, applications can benefit from both.
(Perhaps the reason is that this would somehow break a merge behavior in a
way that I do not understand?)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org