incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Seaborne (JIRA)" <>
Subject [jira] [Commented] (JENA-111) Improving TopN optimization in case of an intermediate OpModifier
Date Wed, 07 Sep 2011 13:00:10 GMT


Andy Seaborne commented on JENA-111:

(project) does change the number of rows and (slice) does not depend on the columns/variables,
so the optimization which is the connection of slice and order by, is unaffected by pushing
projection around.  In ARQ project is a mask, it does not matter is it is inside or outside
the slice but it's better to keep it in the right place.

4 looks right.

3 is harder because DISTINCT interacts with projection.  The transformation above isn't right
because distinct changes the number rows, so topN may not generate enough unique rows for
the slice.  It sin't possible statically, without reference to the data to know the right
value for N in X+N.  This one needs some further thinking.

> Improving TopN optimization in case of an intermediate OpModifier
> -----------------------------------------------------------------
>                 Key: JENA-111
>                 URL:
>             Project: Jena
>          Issue Type: Improvement
>          Components: ARQ
>            Reporter: Sara Magliacane
>            Assignee: Paolo Castagna
>            Priority: Minor
>              Labels: arq, optimization
>         Attachments: topk_project.patch
> In the TopN optimization (Jena-89)  it would be useful to handle also the case in which
there are some other OpModifiers (I think they are the only category of Ops that can be in
that position in the tree) between Slice and Order By, for example OpProject:
> (slice _1
>   (project ?s ...
>     (order by <condition>
> -> 
> (project ?s ...
>   (top 1 <condition>

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message