> "DataGuides serve as dynamic schemas, generated from the database." What we 
> generate is a 
> schema from the query. 

Still, it is a data schema, not a query schema. The one in the paper would be a 
Database DataGuide and ours would be Query DataGuide. I would agree to change 
it to QueryDataguide but I don't think there would be any confusions if it was 
simply called Dataguide.

> I think we will run into a problem. 28msec has only one buffer that is 
> accessed by all db:collection() calls in a query. Hence, the information 
> needs to be the union.

If there is no way of removing that limitation then we can overcome this by 
doing an union on all db:collection() dataguides and this will ensure 
correctness. But it would be a pity to loose the individually computed 
dataguides for each separate call. Still, if the name of fields of different 
collections are mostly disjoint sets, then we won't loose much of the 

Again I suggest leaving this until I start implementing the push-down of 
projection info into the db:collection() calls. It has no impact on jn:parse() 
-- these dataguides can still be computed and kept individually for each call 
even if we do an union on db:collection() calls.


Your team Zorba Coders is subscribed to branch lp:zorba.

Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to