Add `db.getMany(keys)` across the board
vweevers opened this issue ยท 8 comments
Background: Level/abstract-leveldown#380 and Level/levelup#491.
-
level-supports
: Level/supports#11 (2.0.1) -
abstract-leveldown
: Level/abstract-leveldown#381 (7.2.0) -
leveldown
: Level/leveldown#787 (6.1.0) -
memdown
: Level/memdown#212 (6.1.0) -
level-js
: Level/level-js#214 (6.1.0) -
deferred-leveldown
: Level/deferred-leveldown#89 (7.0.0) -
encoding-down
: Level/encoding-down#102 (7.1.0) -
levelup
: Level/levelup#725 (5.1.0) -
subleveldown
: Level/subleveldown#107 (6.0.0) -
multileveldown
: Level/multileveldown@ff1ba48 (5.0.0) -
level-party
: 5.1.0 -
level-mem
: 6.0.0 -
level
: Level/level#207 -
rocksdb
: Level/rocksdb#184 (5.2.0) -
I moved this remaining item to Level/level-rocksdb#75level-rocksdb
: just docs
I'll try with the rockdb port to help out if no one was already doing it. I also need to check the typings on DT as they're broken after the 'default' export removals. So I'll start adding getMany at same time.
Go for it, thanks! Note that on rocksdb we must first port Level/leveldown#783, Level/leveldown#784, Level/leveldown#785 (in that order), and then Level/leveldown#787.
I'll try with the rockdb port to help out if no one was already doing it. I also need to check the typings on DT as they're broken after the 'default' export removals. So I'll start adding getMany at same time.
Just asking, do you plan to use the rocksdb's native getMany
interface to implementing this?
I would prefer that we don't, because it will increase the code diff between leveldown
and rocksdb
, making cherry-picking commits from one to the other more work. In addition, the leveldown
code is written in anticipation of additional features like iterator.all()
which will reuse common functions.
Just asking, do you plan to use the rocksdb's native
getMany
interface to implementing this?
That is what I was looking to do...
I would prefer that we don't, because it will increase the code diff between leveldown and rocksdb
... but I guess not. :D
I don't think I know enough to do it tbh: the low-hanging method I was targetting to call:
virtual std::vector<Status> MultiGet(const ReadOptions& options,
const std::vector<Slice>& keys,
std::vector<std::string>* values) {
has the comment:
Consistent Get of many keys across column families without the need
for an explicit snapshot. NOTE: the implementation of this MultiGet API
does not have the performance benefits of the void-returning MultiGet
functions.
So:
- a) the Worker is doing
options_.snapshot = database->NewSnapshot();
and I'm not sure if (as per comment) whether this will be used. and - b) that bar basic reduction in cross-domain calls, that there would actually be performance benefit of changing it to rocksdb's native MultiGet unless it also handles passing through column_family handles.
Probably makes sense to just do all cherry picking for now.
@vweevers @MeirionHughes Just confirming anyone of you are going to implementing this for rocksdb? Just eager to try the new interface :)
Types are still missing getMany
. Opened an issue in the levelup
repo.
Disappointed ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ๐ญ