technically, processing a view needs to traverse the b-tree, so if I’m not mistaken it should be O(log(n)). If you want O(1), you should look at preprocessing your data so you can fetch it through a key/value “get” command. This will be much quicker, but of course requires more logic to implement.
Note that of course your query is proportional to the number of keys, because you are emitting one item into the index, for every document that matches.
If you need to fetch a list of keys very quickly, I recommend you caching them in a separate document and access it through key/value.
Today is all keys in bucket but tomorrow I would like, for example, to get all keys, in one get, for e.g., all beer keys from a brewery. I mean that the view should prepare values for each key where the key is the brewery and the value is a csv of all the beer keys from that brewery.
This will enable me to get all the keys in a quick get and batch get the beers’ documents in a second step
Let me rephrase.
I want to use views for lookups (like in the beer example above). The view works offline preparing the relevant doc ids and when need arise, I call the view with a specific key and the view should return the pre-calculated IDs.
The return duration should be independent of the database size as it was already calculated.
Thus, reading the view should be as fast as accessing a single key and not a function of the return dataset size