Processing time for some queries

[gcelano]

There are a few queries that require a long processing time and during which the server becomes so busy that it cannot accept further ANNIS queries. For Example, the following query takes minutes because of .* (but note that it is limited by @* author="Homer" and I was expecting it to be rather fast):

pos="n" ->dep[dep_fnc="ATR"] pos="n" & #1 ->dep[dep_fnc="ATR"] pos="l" 
& #2 .* #1 & #3 .* #2 &  case="g" _ident_ #2 @* author="Homer"

while the following is very fast:

pos="n" ->dep[dep_fnc="ATR"] pos="n" & #1 ->dep[dep_fnc="ATR"] pos="l" 
& #2 .1,3 #1 & #3 .1,3 #2 &  case="g" _ident_ #2 @* author="Homer"

More in general, it would helpful if there were a way to limit processing time/absorbtion of resources, even if this means that the results cannot be returned. A "stop button" would also be helpful, in case one notices that ANNIS is taking too much time.

UPDATE 4/2/2025

I notice that Annis goes into an infinite loop also with specific queries such as

pos=‎"v‎" & pos=‎"n‎" @* author=‎"Quintus Smyrnaeus‎" & #1 ->dep[dep_fnc=‎"OBJ‎"] #2

If I add #1 . #2 , however, it works super fast.

[thomaskrause]

A stop button is something that has been on the TODO-list for a long time but was difficult to implement due to the limitations of the current REST API. But there is a query_timeout setting in the [database] section which was not documented yet but would help to avoid endless queries (the documentation will be fixed in the next release)

[database]
graphannis = "data/"
sqlite = "service.sqlite"
# Optional timeout for queries in seconds. No timeout is applied if parameter is
# not given.
query_timeout = 60

I am still investigating why these queries take forever to execute, but I can reproduce these issues on the oga_v0.2.0_1 corpus

[thomaskrause]

Output of the query planner for the first query.

+|indexjoin (parallel) (#2 _ident_ #4) [out: 1, sum: 805573, instep: 1]
    +|filter (#3 .* #2) [out: 1, sum: 805572, instep: 1]
        +|indexjoin (parallel) (#1 ->dep [dep_fnc="ATR"] #3) [out: 1, sum: 805571, instep: 1]
            +|filter (#1 ->dep [dep_fnc="ATR"] #2) [out: 1, sum: 805570, instep: 402781]
                +|indexjoin (parallel) (#2 .* #1) [out: 402778, sum: 402789, instep: 402781]
                    +|indexjoin (parallel) (#5 @⃖* #2) [out: 3, sum: 8, instep: 8]
                        #5 (author="Homer") [out: 5, sum: 0, instep: 0]
                        #2 (pos="n") [out: 959465, sum: 0, instep: 0]
                    #1 (pos="n") [out: 959465, sum: 0, instep: 0]
            #3 (pos="l") [out: 553537, sum: 0, instep: 0]
    #4 (case="g") [out: 590866, sum: 0, instep: 0]

author="Homer" is indeed the main limitation graphANNIS uses find the initial matches. All document nodes with author="Homer" are joined with all pos="n" nodes. The #3 .* #2 condition is only used as filter, which seems odd and needs further investigation.

Also, the output size of the inner join is extremly underestimated

+|indexjoin (parallel) (#5 @⃖* #2) [out: 3, sum: 8, instep: 8]
                        #5 (author="Homer") [out: 5, sum: 0, instep: 0]
                        #2 (pos="n") [out: 959465, sum: 0, instep: 0]

It returns 48687 instead of 3 matches.

[thomaskrause]

This is fixed in the main branch and will be part of the next release.
The additional #1 . #2 still help in performance because this additional constraint can be used for a more specific search. But omitting it does give a result in a reasonable time (just under 1 second on my laptop).

The issue was that the @* relation output was heavily underestimated and pushed down the processing stream. The very expensive filter operations were executed too early and with a much higher number of tuples than expected.

The new plan for the same query is more accurate:

+|filter (#3 .* #2) [out: 1, sum: 1061690, instep: 23]
    +|filter (#2 .* #1) [out: 3, sum: 1061667, instep: 23]
        +|indexjoin (parallel) (#2 _ident_ #4) [out: 23, sum: 1061644, instep: 23]
            +|indexjoin (parallel) (#2 @* #5) [out: 23, sum: 1061621, instep: 1255]
                +|indexjoin (parallel) (#1 ->dep [dep_fnc="ATR"] #2) [out: 1232, sum: 1060366, instep: 30812]
                    +|indexjoin (parallel) (#1 ->dep [dep_fnc="ATR"] #3) [out: 25678, sum: 1029554, instep: 1029554]
                        #1 (pos="n") [out: 922562, sum: 0, instep: 0]
                        #3 (pos="l") [out: 535086, sum: 0, instep: 0]
                    #2 (pos="n") [out: 922562, sum: 0, instep: 0]
                #5 (author="Homer") [out: 5, sum: 0, instep: 0]
            #4 (case="g") [out: 590866, sum: 0, instep: 0]

Instead of finding all pos=n annotations in texts with the author Homer, it first searches for the pos="n ->dep [dep_fnc="ATR"] pos="l" relations and effectively pushes the filter operations up.

[thomaskrause]

Also as a remark, after the ANNIS version that contains this fix is released, you have re-import the corpora to get an accurate estimation for the @* queries since I had to change the internal statistics to include a field that helps estimating the outcome.