Count results while printing them, when ignoring pagination #795
Conversation
mattmundell
changed the title
src/manage_sql.c
Outdated
| debugs = f_debugs; | ||
| holes = f_holes; | ||
| infos = f_infos; | ||
| logs = f_logs; | ||
| warnings = f_warnings; | ||
| false_positives = f_false_positives; | ||
| filtered_result_count = debugs + holes + infos + logs + warnings | ||
| + false_positives; |
There was a problem hiding this comment.
Why are you overwriting the full counts with the filtered ones here instead of just adding the filtered counts for filtered_result_count?
Earlier you already get them with report_counts_id_full (...) and while the total is still correct after this the counts per level are not if there are any filter conditions limiting the results selection.
There was a problem hiding this comment.
Oh I misunderstood what the report_counts_id part was doing. Should be right with
299fefa. Thanks for catching. Really want to clean this code up, but need to backport these PRs to gvmd 8.
| @@ -29483,6 +29483,8 @@ print_report_xml_start (report_t report, report_t delta, task_t task, | |||
| "</delta>"); | |||
| } | |||
|
|
|||
| count_filtered = (delta == 0 && ignore_pagination && get->details); | |||
There was a problem hiding this comment.
This could perhaps also be used in any case where the number of rows is unlimited via a rows=-1 in the filter and the "Max Rows" limit is disabled.
If "Max Rows" is enabled it could also be compared against the unfiltered total or some other upper bound that's quick to query to see if using the number of returned results could give the wrong count.
There was a problem hiding this comment.
Sounds like a good idea. Would like to leave it for a later PR though.
Also add a few comments to prevent making the same mistake again.
This skips some counting SQL by counting the results as they are being added
to the response XML.
This is possible because when we ignore_pagination we are getting all the
filtered results anyway, so we can do both the page and filtered counting as we
go through the results.
On my basic test report of 5000 results this saved about 212ms of a 1344ms
report, or 12%. To be clear: that's the time spent in SQL for the GET_REPORTS
call made by the GSA Report page.
Checklist: