On 06/04/11 16:18, Bill Roberts wrote:
Andy
Sorry for slow response from me. I tried adding the line ((TERM ANY
ANY) 10) to the end of the stats.opt file and that increased the
speed of that query to about the same as with no optimiser. So
thanks very much for that - it's kind of solved the problem, but I
need to do some more tests on a broader range of queries, to find the
cases where the optimiser is actively helping (as opposed to no
longer slowing things down!)
I'm be very interested in what you find out. I recently realised why
the fixed optimizer does as well as it does - it has some built-in stats
model that is data independent so on teh surface it looks like it should
sometimes make bad choices. The fixed-ness is only used to choose the
starting point after which it tends to execute connected triple patterns
and so avoids intermediate cross products, which are really bad.
The stats format as generated tdbstats or tdbloader2 is meant to be a
help, not a perfect stats file.
If you know <ifp> is is an inverse functional property,
((ANY <ifp> TERM) 1))
is the right thing to add.
Presumably it's cases where there are multiple clauses in the query
and the order of evaluating them is significant.
Yes.
Anyway, thanks a lot for your help.
Cheers
Bill
Andy
