[
https://issues.apache.org/jira/browse/JENA-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974839#comment-13974839
]
Andy Seaborne commented on JENA-681:
------------------------------------
The comment:
{noformat}
+ /**
+ * Context key controlling whether the main query engine moves filters to
the "best" place using
+ * the more limited and conservative strategy which does not place as
many filters
+ * Default is "true" - filter placement is done.
+ */
{noformat}
is confusing because it does not default to true, it must be set explicitly.
Suggestion:
{noformat}
/**
* Context key controlling whether the main query engine moves filters to the
"best" place using
* the more limited and conservative strategy which does not place as many
filters
* Must be explicitly set "true". Filter placement must also be active (which
it is by default).
* @see ARQ#optFilterPlacement
*/
{noformat}
> Allow the old less aggressive filter placement behaviour to be optionally
> used in place of the newer more aggressive behaviour
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: JENA-681
> URL: https://issues.apache.org/jira/browse/JENA-681
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ, Optimizer
> Affects Versions: Jena 2.11.1
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Fix For: Jena 2.11.2
>
> Attachments: JENA-681.patch
>
>
> In investigating some optimiser caused performance regression issues that
> occurred after we upgraded at Cray to using 2.11.1 it was discovered that the
> new filter pushing was too aggressive for our backend in how it broke up
> BGPs/quadpatterns
> Ideally we would like to use the filter placement mode where we place filters
> without breaking BGPs but as discussed in JENA-627 and JENA-628 (as well as
> other related issues) this behaviour is broken in the 2.11.1 release and
> indeed the specific problem query did get horribly mangled with this mode
> enabled.
> I have been able to verify that the relevant fixes for those bugs means the
> affected query does now get optimised appropriately using the latest trunk
> code and I've added a sanitised version of the relevant query to the test
> cases.
> *However* it would be nice if we had the option of switching back on the more
> conservative pre 2.11.1 filter placement behaviour if we desired. This is
> preserved in {{TransformFilterPlacement_Old}} and currently noted in comments
> that it will be removed in future.
> What I propose to do instead is to rename this to
> {{TransformFilterPlacementConservative}} and add an associated
> {{optFilterPlacementConservative}} flag which when explicitly enabled will
> use the old filter placement behaviour rather than the newer more aggressive
> filter placement behaviour.
> I'll attach a proposed patch for this later today
--
This message was sent by Atlassian JIRA
(v6.2#6252)
