Parallel == multiple-threads across multiple-machines in the cluster? :-)
By definition, temp views don't have no disk IO. It's map/reduce
parallelized in memory directly served back over a TCP socket. Is that
still not going to be fast enough?
K.
On Fri, Apr 10, 2009 at 7:26 PM, Paul Davis wro
On Fri, Apr 10, 2009 at 8:51 PM, kowsik wrote:
> IMHO, the need for view intersections will go away once we have
> parallel map/reduce to the point where _temp_views's are fast!
>
> K.
>
The lower bound for view generation is disk I/O. Temp views will never
be fast enough for production.
HTH,
Pa
IMHO, the need for view intersections will go away once we have
parallel map/reduce to the point where _temp_views's are fast!
K.
On Fri, Apr 10, 2009 at 10:04 AM, Wout Mertens wrote:
>
> On Apr 10, 2009, at 11:46 AM, Sho Fukamachi wrote:
>
>> the obvious followup question to those examples is "
Devendra Gera wrote:
> I recently developed a CouchDB imitation in python for testing, while
> I was working on the document update notifications patch. Maybe I can
> put some effort into porting it to C?
>
> It was a purely in-memory store though.
You might find this link interesting:
http://bre
Your welcome, for one time I can help you and not the opposite
2009/4/10 Paul Davis
> > (let's say we use Level 3)
> > sortKey=[];
> > for (i=0; i<3; i++) {
> > for(j=0; j >sortKey.push(sArray[j][i]);
> > }
> >
> > }
>
> Patrick! A million thanks. Seeing this in code I at first thought,
On Apr 10, 2009, at 11:46 AM, Sho Fukamachi wrote:
the obvious followup question to those examples is "well, how do I
find a document with all of (n) tags?".
How about this algorithm. Needed: tagcount view and document-by-tag view
- given a list of tags that the document should have
- find
If you don't trap exits, then the default OTP behavior is to propagate
linked exit messages to other child linked process, killing the entire
process tree. The exception is for linked normal exits, which have no
effect on non-trapping gen_server processes. They are just ignored. I
think it'
Hi Damien, I see that the basic idea here is to terminate processes
linked to a couch_db, couch_db_updater, couch_ref_counter,
couch_server, or couch_view process even if the processes is doing a
normal termination. I have a couple of questions:
* where do the 'EXIT' messages handled by co
> (let's say we use Level 3)
> sortKey=[];
> for (i=0; i<3; i++) {
> for(j=0; j sortKey.push(sArray[j][i]);
> }
>
> }
Patrick! A million thanks. Seeing this in code I at first thought,
wait, srsly? And then double checking:
S3.1 For each weight level L in the collation element array from 1
Hi Paul,
thanks for the reply - not trying to point out anything! : ) I did
think the original thread made the proposed functionality sound
suspiciously easy to implement! Well, always like this.
I'm still not good enough at Erlang to offer any implementation
comments worth reading, so I'
[
https://issues.apache.org/jira/browse/COUCHDB-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Candler resolved COUCHDB-324.
---
Resolution: Invalid
This is expected behaviour from the Unicode Collation Algorithm. I have
Well,
Just to make a global figure, ICU collation is to binary collation what
CouchDB is to RDBMS.
If you look at the link you gave for algorithm reference, you have :
On 1.1 multi level comparison, you have in the table this example :
L2 Accents role < r*ô*le < roles
To be complete you should a
On Thu, Apr 09, 2009 at 06:59:27PM -0400, Paul Davis wrote:
> Also, I still don't see anything in this damned collation algorithm
> that explains how A < aa.
Maybe it boils down to something like this?
- compare strings considering only primary weights
- only in the case where two strings are ide
13 matches
Mail list logo
