|
Re: Stats for super search look buggy
by pryrt (Abbot) on May 07, 2021 at 21:20 UTC
|
| [reply] |
|
|
| [reply] |
|
|
Well, the percentage calculator could be presumably changed to something like
use constant jump => 9866219;
my $delta = $last_node_in_search_range - $first_node_in_search_range;
$delta -= jump if $delta > jump;
my $percent = 100 * $delta / ($most_recent_node_id - jump);
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
|
| [reply] |
|
|
| [reply] |
Re: Stats for super search look buggy
by jdporter (Paladin) on May 20, 2021 at 18:58 UTC
|
| [reply] |
|
|
FYI: first search results page just showed me "Press <Next> to continue searching remaining 707.00% of DB." In case it's relevant, this was a search for all of qw{ dump opaque object } in any text. The next page showed something more reasonable (remaining 89.4%, or somesuch).
| [reply] |
|
|
| [reply] |
|
|
Thanks, as promised I wanted to do it myself this weekend (Pentecost brings an extra holiday in DE :)
> Please let me know whether things look better now
They definitely look better now, but it's still weird
Please try this search
The first reply looks OK
Found 50 nodes roughly between 2021-05-20 and 2018-06-02 (searched 4.
+01% of DB).
...
Press [NEXT >] to continue searching remaining 95.99% of DB.
but after [NEXT] it doesn't add up anymore
Found 50 nodes roughly between 2018-06-02 and 2015-02-16 (searched 7.
+80% of DB).
...
Press [NEXT >] to continue searching remaining 88.18% of DB.
That's less than 100%
If you want I can care about it this weekend.
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
Re: Stats for super search look buggy
by LanX (Saint) on May 30, 2022 at 12:27 UTC
|
Not sure if this is still the same bug, but I got this today around "May 30, 2022 at 13:56 CEST"
Remainder of query was not run (used 10.01 seconds so far)
Found 0 nodes roughly between 2022-05-30 and 0 (searched 567.28% of DB).
where any text contains all of "debugger", "ornament"
Date: Author/owner: Title: Node type:
Press >NEXT< to continue searching remaining 304.68% of DB.
Please be patient after submitting your search.
Link to preload this search: ?node_id=3989;BIT=debugger%20ornament
(emphasize added)
Please note the 0 too, there seems to be a date problem in edge cases causing such high percentages ...
EDIT
Couldn't reproduce it now, probably dependent on other side effects.
update
Kind of a Heisenbug, if you run the exact same search, you'll end up in this new node now.
You need an "impossible" query to force a "Found 0 nodes" response.
update
My best guess, this happens only if the 10sec timeout ends above the giant jump from 2019, i.e. the server must be busy and this problem will happen more and more often in the future.
| [reply] |
