You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have three different physical operators for performing a (batched) bind join at a SPARQL endpoint: PhysicalOpBindJoinWithFILTER, PhysicalOpBindJoinWithUNION, and PhysicalOpBindJoinWithVALUES. Currently, the filter-based one is used as the default when converting a logical plan into a physical one and this decision is hardcoded in the corresponding convert functions of LogicalToPhysicalOpConverter.
This issue is about extending the RDF-based configuration of HeFQUIN such that the decision configured. I am not sure yet how this can best be done. A starting point might be to extend the constructor of LogicalToPhysicalPlanConverterImpl.
(Note to myself: This is relevant only when using a physical optimizer that converts the given logical plan into a physical plan, which not all the optimizers that we have do. For instance, for the optimizers that create the physical join subplans in a bottom-up fashion (e.g., greedy or via dynamic programming) this is irrelevant; they consider all the possible types of bind join operators.)
The text was updated successfully, but these errors were encountered:
We have three different physical operators for performing a (batched) bind join at a SPARQL endpoint:
PhysicalOpBindJoinWithFILTER
,PhysicalOpBindJoinWithUNION
, andPhysicalOpBindJoinWithVALUES
. Currently, the filter-based one is used as the default when converting a logical plan into a physical one and this decision is hardcoded in the correspondingconvert
functions ofLogicalToPhysicalOpConverter
.This issue is about extending the RDF-based configuration of HeFQUIN such that the decision configured. I am not sure yet how this can best be done. A starting point might be to extend the constructor of
LogicalToPhysicalPlanConverterImpl
.(Note to myself: This is relevant only when using a physical optimizer that converts the given logical plan into a physical plan, which not all the optimizers that we have do. For instance, for the optimizers that create the physical join subplans in a bottom-up fashion (e.g., greedy or via dynamic programming) this is irrelevant; they consider all the possible types of bind join operators.)
The text was updated successfully, but these errors were encountered: