Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Batch get/getAll #376

Open
cyanfish opened this issue Feb 18, 2022 · 3 comments
Open

Batch get/getAll #376

cyanfish opened this issue Feb 18, 2022 · 3 comments
Labels
feature request queries TPAC2024 Topic for discussion at TPAC 2024

Comments

@cyanfish
Copy link

Currently the only way to query a set of individual rows by key is to use repeated calls to get or getAll. We have some use cases where we want to query many keys with one row each (e.g. the equivalent of SQL WHERE id IN (1,3,9,...)), where the event loop potentially adds quite a bit of overhead.

Another option would be to add a batch method for get and/or getAll, for example:

request = store.batchGetAll(keyRangeArray) 
request = index.batchGetAll(keyRangeArray)

Which would return an array of arrays corresponding to the input array.

The Chrome team did some internal prototyping and found that in the best case (1 row per key) there is potential for a 3x speedup over mutliple parallel getAll calls. That hasn't been proven in real world use cases yet and it's unclear if other browsers would see the same improvements, but that would be a significant speedup that can't be replicated with the current APIs.

@tophf
Copy link

tophf commented Mar 30, 2022

there is potential for a 3x speedup over mutliple parallel getAll calls

Is the base version using a single transaction with three getAll requests or three separate transactions?

@cyanfish
Copy link
Author

The test I'm referring to used a single transaction with N getAll requests in parallel vs 1 prototype batchGetAll call with N ranges. N=100 to N=100k were tested.

@w3c w3c deleted a comment from Line2588 Jul 25, 2023
@SteveBeckerMSFT SteveBeckerMSFT added the TPAC2024 Topic for discussion at TPAC 2024 label Sep 9, 2024
@SteveBeckerMSFT
Copy link

TPAC 2024: We agreed this proposal makes sense. Much [like getAllEntries()])#206 (comment)), reading more data in a single IDBRequest could maybe reduce event loop overhead to improve performance. We may want to relax the ordering of the results to provide some implementation flexibility which could enable browsers to optimize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request queries TPAC2024 Topic for discussion at TPAC 2024
Projects
None yet
Development

No branches or pull requests

5 participants
@inexorabletash @tophf @cyanfish @SteveBeckerMSFT and others