If you need a relatively small list of partition keys, (let's say you want to allow a user to paginate through the partition keys in blocks of 10, say) then it's probably more efficient to perform a sequence of calls to _all_docs, fetching the "first" document of each partition key like so:
https://gist.github.com/glynnbird/73fea65a12b0c420562108a80ea0c449 This consumes one _all_docs?limit=1 request per partition key you need and may be more efficient than reading all the ids in a database. <https://gist.github.com/glynnbird/73fea65a12b0c420562108a80ea0c449> On Mon, 25 May 2020 at 00:30, ermouth <ermo...@gmail.com> wrote: > Thanks! > > > comp sci theoretically nothing that’ll be any more > > efficient internally than the obvious map/reduce view > > This probably doesn’t hold in real world at least for DBs you know upfront > have number_of_partitions ≃ number_of_docs < several_thousands. Reading all > _id-s without reduce is likely cheaper in that case. Which means I might > just read _id-s for DBs having say < 10k docs, without writing a ddoc with > map/reduce view and waiting it to warm up. Or I can allow user to choose > what to do. > > ermouth > > > пн, 25 мая 2020 г. в 01:58, Paul Davis <paul.joseph.da...@gmail.com>: > > > Currently no, and comp sci theoretically nothing that’ll be any more > > efficient internally than the obvious map/reduce view. > > > > On Sun, May 24, 2020 at 12:48 PM ermouth <ermo...@gmail.com> wrote: > > > > > Hi devs, > > > > > > is there a way to get the list of DB partitions, except dedicated > > > map/reduce? Trying to add partitioned queries UI into Photon and bit > > stuck > > > how to implement it. > > > > > > ermouth > > > > > >