You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Robert Vesse <rv...@cray.com> on 2011/11/28 19:22:06 UTC
Disabling TransformFilterEquality optimisation
Hey All
We're looking to disable TransformFilterEquality because for our query engine it generates an algebra that we can't process (because it uses extend and we only support SPARQL 1.0 operations currently). Initially we just reversed the obvious part of this optimisation in our Transform by turning extend back into filter = but we've now noticed that TransformFilterEquality doesn't just switch filter for extend but it actually substitutes the constant for the variable in the inner algebra operations. So when our engine hits the recreated filter the variable in question doesn't exist so it blindly filters everything out.
So having traced the code paths for optimization I can see that in Optimize.rewrite() it applies a bunch of different optimizations depending on what context symbols are set. AFAICT it should be a simple case of setting the symbol ARQ.optFilterEquality to be false
My concern is that in the last ARQ release this was marked deprecated but in the latest trunk it is not so what is the actual status of this switch? We need to use it so we'd really like to see it stay in ARQ
Regards,
Rob Vesse
Re: Disabling TransformFilterEquality optimisation
Posted by Andy Seaborne <an...@apache.org>.
On 28/11/11 20:53, Robert Vesse wrote:
> We're using Eclipse Indigo Jave EE edition so not sure if that makes a difference
I have
Eclipse Indigo Java Developers Edition - SR1
Andy
>
> Rob
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
> Sent: Monday, November 28, 2011 12:51 PM
> To: jena-users@incubator.apache.org
> Subject: Re: Disabling TransformFilterEquality optimisation
>
> On 28/11/11 20:43, Robert Vesse wrote:
>> We're using ARQ 2.8.8, I can see that filterPlacement is marked deprecated in the code but Eclipse also displays optFilterEquality with the strikethrough formatting which AFAIK indicates deprecation. I wonder if this is a just a case of Eclipse getting confused?
>
> Possibly - the @Deprecated is before the javadoc. I'll swap them in
> case it's that.
>
> I don't see it with strikethrough (Eclipse Indigo) though.
>
> Andy
>
>>
>> Thanks,
>>
>> Rob
>>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
>> Sent: Monday, November 28, 2011 12:37 PM
>> To: jena-users@incubator.apache.org
>> Subject: Re: Disabling TransformFilterEquality optimisation
>>
>> On 28/11/11 18:22, Robert Vesse wrote:
>>> Hey All
>>>
>>> We're looking to disable TransformFilterEquality because for our
>>> query engine it generates an algebra that we can't process (because
>>> it uses extend and we only support SPARQL 1.0 operations currently).
>>> Initially we just reversed the obvious part of this optimisation in
>>> our Transform by turning extend back into filter = but we've now
>>> noticed that TransformFilterEquality doesn't just switch filter for
>>> extend but it actually substitutes the constant for the variable in
>>> the inner algebra operations. So when our engine hits the recreated
>>> filter the variable in question doesn't exist so it blindly filters
>>> everything out.
>>>
>>> So having traced the code paths for optimization I can see that in
>>> Optimize.rewrite() it applies a bunch of different optimizations
>>> depending on what context symbols are set. AFAICT it should be a
>>> simple case of setting the symbol ARQ.optFilterEquality to be false
>>>
>>> My concern is that in the last ARQ release this was marked deprecated
>>> but in the latest trunk it is not so what is the actual status of
>>> this switch? We need to use it so we'd really like to see it stay in
>>> ARQ
>>
>> Rob,
>>
>> There no plans to remove or change optFilterEquality but which version
>> are you referring to?
>>
>> In the last release (2.8.8) "filterPlacement" was marked deprecated with
>> javadoc saying "use optFilterPlacement". The same is true in the
>> current code. There was some renaming awhiel ago to put "opt" on the
>> front of all switches.
>>
>> 2.8.8 (and 2.8.7, 2.8.6, 2.8.5, 2.8.4 !!)
>>
>> @Deprecated
>> /** @deprecated Use optFilterPlacement */
>> public static final Symbol filterPlacement = optFilterPlacement ;
>>
>> /**
>> * Context key controlling whether the standard optimizer applies
>> * optimizations to equalities in FILTERs.
>> * This optimization is conservative - it does not take place if
>> * there is a potential risk of changing query semantics.
>> */
>> public static final Symbol optFilterEquality =
>> ARQConstants.allocSymbol("optFilterEquality") ;
>>
>> Andy
>>
>>
>>>
>>> Regards,
>>>
>>> Rob Vesse
>>>
>>
>
RE: Disabling TransformFilterEquality optimisation
Posted by Robert Vesse <rv...@cray.com>.
We're using Eclipse Indigo Jave EE edition so not sure if that makes a difference
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Monday, November 28, 2011 12:51 PM
To: jena-users@incubator.apache.org
Subject: Re: Disabling TransformFilterEquality optimisation
On 28/11/11 20:43, Robert Vesse wrote:
> We're using ARQ 2.8.8, I can see that filterPlacement is marked deprecated in the code but Eclipse also displays optFilterEquality with the strikethrough formatting which AFAIK indicates deprecation. I wonder if this is a just a case of Eclipse getting confused?
Possibly - the @Deprecated is before the javadoc. I'll swap them in
case it's that.
I don't see it with strikethrough (Eclipse Indigo) though.
Andy
>
> Thanks,
>
> Rob
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
> Sent: Monday, November 28, 2011 12:37 PM
> To: jena-users@incubator.apache.org
> Subject: Re: Disabling TransformFilterEquality optimisation
>
> On 28/11/11 18:22, Robert Vesse wrote:
>> Hey All
>>
>> We're looking to disable TransformFilterEquality because for our
>> query engine it generates an algebra that we can't process (because
>> it uses extend and we only support SPARQL 1.0 operations currently).
>> Initially we just reversed the obvious part of this optimisation in
>> our Transform by turning extend back into filter = but we've now
>> noticed that TransformFilterEquality doesn't just switch filter for
>> extend but it actually substitutes the constant for the variable in
>> the inner algebra operations. So when our engine hits the recreated
>> filter the variable in question doesn't exist so it blindly filters
>> everything out.
>>
>> So having traced the code paths for optimization I can see that in
>> Optimize.rewrite() it applies a bunch of different optimizations
>> depending on what context symbols are set. AFAICT it should be a
>> simple case of setting the symbol ARQ.optFilterEquality to be false
>>
>> My concern is that in the last ARQ release this was marked deprecated
>> but in the latest trunk it is not so what is the actual status of
>> this switch? We need to use it so we'd really like to see it stay in
>> ARQ
>
> Rob,
>
> There no plans to remove or change optFilterEquality but which version
> are you referring to?
>
> In the last release (2.8.8) "filterPlacement" was marked deprecated with
> javadoc saying "use optFilterPlacement". The same is true in the
> current code. There was some renaming awhiel ago to put "opt" on the
> front of all switches.
>
> 2.8.8 (and 2.8.7, 2.8.6, 2.8.5, 2.8.4 !!)
>
> @Deprecated
> /** @deprecated Use optFilterPlacement */
> public static final Symbol filterPlacement = optFilterPlacement ;
>
> /**
> * Context key controlling whether the standard optimizer applies
> * optimizations to equalities in FILTERs.
> * This optimization is conservative - it does not take place if
> * there is a potential risk of changing query semantics.
> */
> public static final Symbol optFilterEquality =
> ARQConstants.allocSymbol("optFilterEquality") ;
>
> Andy
>
>
>>
>> Regards,
>>
>> Rob Vesse
>>
>
Re: Disabling TransformFilterEquality optimisation
Posted by Andy Seaborne <an...@apache.org>.
On 28/11/11 20:43, Robert Vesse wrote:
> We're using ARQ 2.8.8, I can see that filterPlacement is marked deprecated in the code but Eclipse also displays optFilterEquality with the strikethrough formatting which AFAIK indicates deprecation. I wonder if this is a just a case of Eclipse getting confused?
Possibly - the @Deprecated is before the javadoc. I'll swap them in
case it's that.
I don't see it with strikethrough (Eclipse Indigo) though.
Andy
>
> Thanks,
>
> Rob
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
> Sent: Monday, November 28, 2011 12:37 PM
> To: jena-users@incubator.apache.org
> Subject: Re: Disabling TransformFilterEquality optimisation
>
> On 28/11/11 18:22, Robert Vesse wrote:
>> Hey All
>>
>> We're looking to disable TransformFilterEquality because for our
>> query engine it generates an algebra that we can't process (because
>> it uses extend and we only support SPARQL 1.0 operations currently).
>> Initially we just reversed the obvious part of this optimisation in
>> our Transform by turning extend back into filter = but we've now
>> noticed that TransformFilterEquality doesn't just switch filter for
>> extend but it actually substitutes the constant for the variable in
>> the inner algebra operations. So when our engine hits the recreated
>> filter the variable in question doesn't exist so it blindly filters
>> everything out.
>>
>> So having traced the code paths for optimization I can see that in
>> Optimize.rewrite() it applies a bunch of different optimizations
>> depending on what context symbols are set. AFAICT it should be a
>> simple case of setting the symbol ARQ.optFilterEquality to be false
>>
>> My concern is that in the last ARQ release this was marked deprecated
>> but in the latest trunk it is not so what is the actual status of
>> this switch? We need to use it so we'd really like to see it stay in
>> ARQ
>
> Rob,
>
> There no plans to remove or change optFilterEquality but which version
> are you referring to?
>
> In the last release (2.8.8) "filterPlacement" was marked deprecated with
> javadoc saying "use optFilterPlacement". The same is true in the
> current code. There was some renaming awhiel ago to put "opt" on the
> front of all switches.
>
> 2.8.8 (and 2.8.7, 2.8.6, 2.8.5, 2.8.4 !!)
>
> @Deprecated
> /** @deprecated Use optFilterPlacement */
> public static final Symbol filterPlacement = optFilterPlacement ;
>
> /**
> * Context key controlling whether the standard optimizer applies
> * optimizations to equalities in FILTERs.
> * This optimization is conservative - it does not take place if
> * there is a potential risk of changing query semantics.
> */
> public static final Symbol optFilterEquality =
> ARQConstants.allocSymbol("optFilterEquality") ;
>
> Andy
>
>
>>
>> Regards,
>>
>> Rob Vesse
>>
>
RE: Disabling TransformFilterEquality optimisation
Posted by Robert Vesse <rv...@cray.com>.
We're using ARQ 2.8.8, I can see that filterPlacement is marked deprecated in the code but Eclipse also displays optFilterEquality with the strikethrough formatting which AFAIK indicates deprecation. I wonder if this is a just a case of Eclipse getting confused?
Thanks,
Rob
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf Of Andy Seaborne
Sent: Monday, November 28, 2011 12:37 PM
To: jena-users@incubator.apache.org
Subject: Re: Disabling TransformFilterEquality optimisation
On 28/11/11 18:22, Robert Vesse wrote:
> Hey All
>
> We're looking to disable TransformFilterEquality because for our
> query engine it generates an algebra that we can't process (because
> it uses extend and we only support SPARQL 1.0 operations currently).
> Initially we just reversed the obvious part of this optimisation in
> our Transform by turning extend back into filter = but we've now
> noticed that TransformFilterEquality doesn't just switch filter for
> extend but it actually substitutes the constant for the variable in
> the inner algebra operations. So when our engine hits the recreated
> filter the variable in question doesn't exist so it blindly filters
> everything out.
>
> So having traced the code paths for optimization I can see that in
> Optimize.rewrite() it applies a bunch of different optimizations
> depending on what context symbols are set. AFAICT it should be a
> simple case of setting the symbol ARQ.optFilterEquality to be false
>
> My concern is that in the last ARQ release this was marked deprecated
> but in the latest trunk it is not so what is the actual status of
> this switch? We need to use it so we'd really like to see it stay in
> ARQ
Rob,
There no plans to remove or change optFilterEquality but which version
are you referring to?
In the last release (2.8.8) "filterPlacement" was marked deprecated with
javadoc saying "use optFilterPlacement". The same is true in the
current code. There was some renaming awhiel ago to put "opt" on the
front of all switches.
2.8.8 (and 2.8.7, 2.8.6, 2.8.5, 2.8.4 !!)
@Deprecated
/** @deprecated Use optFilterPlacement */
public static final Symbol filterPlacement = optFilterPlacement ;
/**
* Context key controlling whether the standard optimizer applies
* optimizations to equalities in FILTERs.
* This optimization is conservative - it does not take place if
* there is a potential risk of changing query semantics.
*/
public static final Symbol optFilterEquality =
ARQConstants.allocSymbol("optFilterEquality") ;
Andy
>
> Regards,
>
> Rob Vesse
>
Re: Disabling TransformFilterEquality optimisation
Posted by Andy Seaborne <an...@apache.org>.
On 28/11/11 18:22, Robert Vesse wrote:
> Hey All
>
> We're looking to disable TransformFilterEquality because for our
> query engine it generates an algebra that we can't process (because
> it uses extend and we only support SPARQL 1.0 operations currently).
> Initially we just reversed the obvious part of this optimisation in
> our Transform by turning extend back into filter = but we've now
> noticed that TransformFilterEquality doesn't just switch filter for
> extend but it actually substitutes the constant for the variable in
> the inner algebra operations. So when our engine hits the recreated
> filter the variable in question doesn't exist so it blindly filters
> everything out.
>
> So having traced the code paths for optimization I can see that in
> Optimize.rewrite() it applies a bunch of different optimizations
> depending on what context symbols are set. AFAICT it should be a
> simple case of setting the symbol ARQ.optFilterEquality to be false
>
> My concern is that in the last ARQ release this was marked deprecated
> but in the latest trunk it is not so what is the actual status of
> this switch? We need to use it so we'd really like to see it stay in
> ARQ
Rob,
There no plans to remove or change optFilterEquality but which version
are you referring to?
In the last release (2.8.8) "filterPlacement" was marked deprecated with
javadoc saying "use optFilterPlacement". The same is true in the
current code. There was some renaming awhiel ago to put "opt" on the
front of all switches.
2.8.8 (and 2.8.7, 2.8.6, 2.8.5, 2.8.4 !!)
@Deprecated
/** @deprecated Use optFilterPlacement */
public static final Symbol filterPlacement = optFilterPlacement ;
/**
* Context key controlling whether the standard optimizer applies
* optimizations to equalities in FILTERs.
* This optimization is conservative - it does not take place if
* there is a potential risk of changing query semantics.
*/
public static final Symbol optFilterEquality =
ARQConstants.allocSymbol("optFilterEquality") ;
Andy
>
> Regards,
>
> Rob Vesse
>