Rich Megginson wrote:
On 09/12/2013 07:08 PM, David Boreham wrote:
On 9/11/2013 11:41 AM, Howard Chu wrote:
Just out of curiosity, why is keeping a count per key a problem? If
you're using BDB duplicate key support, can't you just use
cursor-c_count() to get this? I.e., BDB already
On 09/12/2013 07:08 PM, David Boreham wrote:
On 9/11/2013 11:41 AM, Howard Chu wrote:
Just out of curiosity, why is keeping a count per key a problem? If
you're using BDB duplicate key support, can't you just use
cursor-c_count() to get this? I.e., BDB already maintains key counts
On 09/13/2013 02:39 PM, David Boreham wrote:
On 9/13/2013 2:18 PM, Rich Megginson wrote:
On 09/12/2013 07:08 PM, David Boreham wrote:
On 9/11/2013 11:41 AM, Howard Chu wrote:
Just out of curiosity, why is keeping a count per key a problem? If
you're using BDB duplicate key support, can't
On 09/12/2013 07:39 AM, thierry bordaz wrote:
On 09/10/2013 04:35 PM, Ludwig Krispenz wrote:
On 09/10/2013 04:29 PM, Rich Megginson wrote:
On 09/10/2013 01:47 AM, Ludwig Krispenz wrote:
On 09/09/2013 07:19 PM, Rich Megginson wrote:
On 09/09/2013 02:27 AM, Ludwig Krispenz wrote:
On
On 09/12/2013 04:40 PM, Rich Megginson wrote:
On 09/12/2013 07:39 AM, thierry bordaz wrote:
On 09/10/2013 04:35 PM, Ludwig Krispenz wrote:
On 09/10/2013 04:29 PM, Rich Megginson wrote:
On 09/10/2013 01:47 AM, Ludwig Krispenz wrote:
On 09/09/2013 07:19 PM, Rich Megginson wrote:
On
On 9/9/2013 11:19 AM, Rich Megginson wrote:
Thanks everyone for the comments. I have added Noriko's suggestion:
http://port389.org/wiki/Design/Fine_Grained_ID_List_Size
David, Ludwig: Does the current design address your concerns, and/or
provide the necessary first step for further
On 9/11/2013 11:41 AM, Howard Chu wrote:
Just out of curiosity, why is keeping a count per key a problem? If
you're using BDB duplicate key support, can't you just use
cursor-c_count() to get this? I.e., BDB already maintains key counts
internally, why not leverage that?
afaik you need
On 09/09/2013 07:19 PM, Rich Megginson wrote:
On 09/09/2013 02:27 AM, Ludwig Krispenz wrote:
On 09/07/2013 05:02 AM, David Boreham wrote:
On 9/6/2013 8:49 PM, Nathan Kinder wrote:
This is a good idea, and it is something that we discussed briefly
off-list. The only downside is that we need
On 09/10/2013 04:29 PM, Rich Megginson wrote:
On 09/10/2013 01:47 AM, Ludwig Krispenz wrote:
On 09/09/2013 07:19 PM, Rich Megginson wrote:
On 09/09/2013 02:27 AM, Ludwig Krispenz wrote:
On 09/07/2013 05:02 AM, David Boreham wrote:
On 9/6/2013 8:49 PM, Nathan Kinder wrote:
This is a good
On 09/09/2013 02:27 AM, Ludwig Krispenz wrote:
On 09/07/2013 05:02 AM, David Boreham wrote:
On 9/6/2013 8:49 PM, Nathan Kinder wrote:
This is a good idea, and it is something that we discussed briefly
off-list. The only downside is that we need to change the index
format to keep a count of
On 09/07/2013 05:02 AM, David Boreham wrote:
On 9/6/2013 8:49 PM, Nathan Kinder wrote:
This is a good idea, and it is something that we discussed briefly
off-list. The only downside is that we need to change the index
format to keep a count of ids for each key. Implementing this isn't
a
Rich Megginson wrote:
Please review and comment:
http://port389.org/wiki/Design/Fine_Grained_ID_List_Size
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Hi Rich,
A nice design! It looks promising to solve the sticky
On 9/6/2013 3:05 PM, Rich Megginson wrote:
Please review and comment:
http://port389.org/wiki/Design/Fine_Grained_ID_List_Size
This looks interesting. I suppose this is similar to a SQL database's
concept of index statistics, and also query hints supplied by the
client. Perhaps more of a
On 9/6/2013 8:49 PM, Nathan Kinder wrote:
This is a good idea, and it is something that we discussed briefly
off-list. The only downside is that we need to change the index
format to keep a count of ids for each key. Implementing this isn't a
big problem, but it does mean that the existing
14 matches
Mail list logo
