I think that I may restrict my ambitions for the distinct-term-scan to the following cases (and their ramifications):

triples:

If any of ?s ?p or ?o are bound for a triples-mode query, then we DO NOT use this rewrite since (a) the pipeline join will be as efficient; and (b) the distinct-term-scan does not bind the other variables so it can not be used to filter them when they are constants.

quads:

The quads indices are:

Therefore, if the graph is bound then we can not use this without a filter except for the special case where DISTINCT ?s is projected since the CSPO index would work.

This also implies that the rewrite can not be applied for quads if either FROM or FROM NAMED is specified since the restriction on the set of named graphs is equivalent to ?g being knownBound.

Note: We MUST NOT use the distinct term scan if there are runtime bindings (either known or maybe bound) for the other variables appearing in the BPG or named graph pattern.

Note: The only way to use this operator when there are known or maybe bound variables is to explicitly add a JOIN (PipelineJoin) after the operator to verify that at least one solution exists for each binding produced by the distinct term operator. Since the pipeline join will introduce duplicates, the DISTINCT can not longer be dropped from the select. At best we can turn it into

This is basically using the distinct-term scan to run the pipeline join with fewer variables.

I think that I may restrict my ambitions for the distinct-term-scan to the following cases (and their ramifications):

triples:

If any of ?s ?p or ?o are bound for a triples-mode query, then we DO NOT use this rewrite since (a) the pipeline join will be as efficient; and (b) the distinct-term-scan does not bind the other variables so it can not be used to filter them when they are constants.

quads:

The quads indices are:

Therefore, if the graph is bound then we can not use this without a filter except for the special case where DISTINCT ?s is projected since the CSPO index would work.

This also implies that the rewrite can not be applied for quads if either FROM or FROM NAMED is specified since the restriction on the set of named graphs is equivalent to ?g being knownBound.

Note: We MUST NOT use the distinct term scan if there are runtime bindings (either known or maybe bound) for the other variables appearing in the BPG or named graph pattern.

Note: The only way to use this operator when there are known or maybe bound variables is to explicitly add a JOIN (PipelineJoin) after the operator to verify that at least one solution exists for each binding produced by the distinct term operator. Since the pipeline join will introduce duplicates, the DISTINCT can not longer be dropped from the select. At best we can turn it into

This is basically using the distinct-term scan to run the pipeline join with fewer variables.