[Bigdata-developers] analysis of 770 and 773: cardinality of ?a p* ?b

[Jeremy J C. <jj...@sy...>]

My commit 7442 introduced some problems while solving

https://sourceforge.net/apps/trac/bigdata/ticket/739


My commit concerned zero length property paths, where the query in trac 739 was misbehaving because a zlpp needs to be run last … the actual estimate could be the number of items in the current graph context, but I put Long.MAX_VALUE (in commit 7442, which should be visible here:
https://github.com/jeremycarroll/bigdata/commit/9f93a2b752bbfcee84f0e8c1047d9a17fcf6223f
)

This had an unintended side effect of marking such ALPPs as not reorder able, because



	public boolean isReorderable() {

		final long estCard = getEstimatedCardinality(null);
		
		return estCard >= 0 && estCard < Long.MAX_VALUE;
		
	}


On my machine I seem to be doing better on the examples from 770 773 and 739 using the (definitely hacky)

public long getEstimatedCardinality(StaticOptimizer opt) {
		
		final JoinGroupNode group = subgroup();

		/*
		 * if lowerBound() is zero, and both ?s and ?o are
		 * variables then we (notionally) match
		 * any subject or object in the triple store,
		 * see:
		 * 
		 * http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#defn_evalPP_ZeroOrOnePath
		 * 
		 * Despite this not being implemented, the optimizer does better
		 * knowing this correctly.
		 */
		if (lowerBound() == 0 && left() instanceof VarNode && right() instanceof VarNode) {
			return Long.MAX_VALUE/2;	
		}
		
		

….

Jeremy J Carroll
Principal Architect
Syapse, Inc.