I'd like to push for getting the multiread map method into the 'downs.
immediate proposal is to add map and _map to abstract-down. where the default (not overridden) map on abstract-down would be a fallback to a simple loop + get.
As per linked issue:;
Con: additional abstract method map on abstract-down to maintain - I doubt this will be a problem as the fallback is using existing methods and it unlikely to ever need touching again.
Pro: allows down's to reduce cross-boundary calls from O(N) to O(1), with further potential saving from using single cache rather than several when returning the result.
Use-case is secondary index lookup. very fast to iterate over primary keys and secondary keys, but the map from secondary key to primary can only currently be implemented with an interator seek + next per row (snapshot) or looping get
just the cross-boundary call reduction (and potential buffering of results) should improve performance, however db's like rocksdb also have native support too
I'd be happy to implement if there are no objections to adding it.
I guess the issue of contention will be the next need to get it into levelup and subleveldown - which might be adding more work as I believe the current plan is to merge up and down?
I'd like to push for getting the multiread
mapmethod into the 'downs.immediate proposal is to add
mapand_mapto abstract-down. where the default (not overridden)mapon abstract-down would be a fallback to a simple loop + get.As per linked issue:;
Con: additional abstract method
mapon abstract-down to maintain - I doubt this will be a problem as the fallback is using existing methods and it unlikely to ever need touching again.Pro: allows down's to reduce cross-boundary calls from O(N) to O(1), with further potential saving from using single cache rather than several when returning the result.
Use-case is secondary index lookup. very fast to iterate over primary keys and secondary keys, but the map from secondary key to primary can only currently be implemented with an interator seek + next per row (snapshot) or looping
getjust the cross-boundary call reduction (and potential buffering of results) should improve performance, however db's like rocksdb also have native support too
I'd be happy to implement if there are no objections to adding it.
I guess the issue of contention will be the next need to get it into levelup and subleveldown - which might be adding more work as I believe the current plan is to merge up and down?