Michael Schmidt

Hey Stas, it strikes me there's something wrong in the way we're using projectInVars vs. joinVars. When filling the distinctProjectionBuffer, we're using projectInVars to project on the incoming solutions (see...

On it -- confirm the reproducer works for me, thanks Stas!

Hi Stas, as I understand using the key vars for join variables would not work -- the constraint for join variables is that they must be guaranteed to be bound....

Looking at the first question again in more detail, I am attaching the two explains (for a data set with 20k triples, all having distinct subjects and objects but the...

Regarding your proposal:" I set the materializeProjectionInQuery variable in the AST2BOpContext class to false and thus I implicitly forced the projection to be materialized outside the plan". Yes, I think...

Regarding your second question, here's the explain for the variant with ORDER BY (executed on some dummy data). As you can see, it contains two ChunkedMaterializationOp's that are expensive, due...

A couple of comments/ideas: 1.) As suggested previously, for your query you should always use FROM: FROM restricts the default graph, which is what's mapped when using "plain" triple patterns,...

Is that text snippet in Figure 2 your input data? What stands out is that the triples ``` ... dct:created "20000101"^^ ... modified "20000101"^^ ``` do not look like valid...

Thanks for your interest in using Blazegraph. First of all, please note that this is _not_ a Blazegraph specific issue. Blazegraph implements the standard, and the behavior that you observe...