Not really
This pattern of unconnected BGPs has legitimate use cases. A common one is
doing similarity calculations where you use unconnected BGPs to create every
possible combination of results and then use BIND and/or FILTER to compute some
metric and use that to filter/rank the combinations.
As others pointed out semantically the evaluation of the two query forms yields
very different intermediate results. It's only the presence of the
post-processing CONSTRUCT stage that happens to strip out the
duplicates/unusable results. Any optimizations MUST preserve the overall
semantics of the query to ensure they yield the same results, so no you
couldn't apply an optimization in this case. In this specific case CONSTRUCT
happens as a post-processing step as part of producing the final query results,
it's not actually within the portion of query evaluation that is subject to
ARQs optimizer.
You could write a query analyzer that would highlight these kinds of potential
issues but ultimately it comes down to the query author understanding what they
are trying to achieve and making the appropriate choice for their use cases.
As I said at the start this pattern has legitimate use cases even if it has
performance implications.
Rob
On 07/10/2021, 12:57, "Élie Roux" <elie.r...@telecom-bretagne.eu> wrote:
> Overall, it whether the WHERE answer is 16*26*2636 rows (all one BGP) or
> 16+26+2636 rows (union).
Yes, I understand better now, thanks!
Do you think there might be some optimization at some point for that
case? I suspect this is very common in SPARQL queries out there...
Best,
--
Elie
