You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by ermouth <er...@gmail.com> on 2020/05/24 17:48:10 UTC
Partitions list
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
Re: Partitions list
Posted by ermouth <er...@gmail.com>.
This is great, thanks!
ermouth
> 25 мая 2020 г., в 10:25, Glynn Bird <gl...@gmail.com> написал(а):
>
> 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 <er...@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 <pa...@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 <er...@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
>>>>
>>>
>>
Re: Partitions list
Posted by Glynn Bird <gl...@gmail.com>.
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 <er...@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 <pa...@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 <er...@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
> > >
> >
>
Re: Partitions list
Posted by ermouth <er...@gmail.com>.
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 <pa...@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 <er...@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
> >
>
Re: Partitions list
Posted by Paul Davis <pa...@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 <er...@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
>