> "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 : email@example.com
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp