I moved the synchronization to the filter, so the functionality is still there
Right, I was just noting that you came to the same conclusion about being able to move it.
I did play around with removing the SyncronizedIterator altogether in the case where no client iterators are present
Hrmm. I wonder how that works for compaction time iterators? Mostly a rhetorical question since you didn't include that change here.
I could subjectively say that the performance difference between not having the Synchronized iterator at all and moving its functionality into the VisibilityFilter was small enough to be hidden in the testing noise, but I don't have evidence to objectively state that.
Ok, I didn't necessarily expect you to have specifics for that either. I brought it up mostly because I was curious. While having the synchronized "barrier" in the iterator stack does make isolate user iterators from mucking up the system iterators, I think I was really wondering if it even makes sense to "encourage" users to write multi-threaded iterators. I know I personally haven't come across any use cases where multiple threads are used effectively by an iterator. Would it make sense to remove the synchronized iterator(filter) from the default "pipeline" and wire up something through the client API and/or table configuration that can let users enable it.
Not implying that this should be done for this ticket, it's just a parallel thought that has some relevancy here.