Topic: [Bug] Tag History Search times out

Posted under Site Bug Reports & Feature Requests

Genjar

Former Staff

Bug overview description.
Searching for pretty much any tag in tag history results in error.

What part(s) of the site page(s) are affected?
https://e621.net/post_tag_history/

What actual behavior is given instead?
Error 500.
The database timed out running your query. Try again later.

...I've tried again for a few weeks, but it never seems to work anymore. Here's one error code: 80007fc82e7d077e60fb399db2307a89

Time of incident (if applicable).
~5:30 GMT - 5:45 GMT

Can you reproduce the bug every time?
Yep.

What steps did you take to replicate this bug?
https://e621.net/post_tag_history/, search for any tag that's used infrequently.

Updated by KiraNoot

This bug is really really annoying, it usually takes about a dozen retries for the some searches to actually go through. I've never had a search that never worked, though.

Updated by anonymous

It needs to be entirely redesigned from the ground up to fix the problems with it. There isn't anything I can do right this moment to make it faster with how it was designed. Not to mention that it doesn't even return meaningful results for what you search for.

Updated by anonymous

Genjar

Former Staff

Oof. So no search for now, guess I'll just get used to that.

KiraNoot said:
Not to mention that it doesn't even return meaningful results for what you search for.

Meaningful enough. Searching for the exact tag was possible with added spaces . And it was handy for finding out how often some tag has been used, useful when making alias/implication suggestions.

Though primarily, I've used it for artist tags. Some users have a habit of constantly replacing Japanese nicks with their own transliterations and such. Which is a problem when you only know the original nick. History search was a quick way to tracking down where the posts have been moved.

Updated by anonymous

Genjar said:
Oof. So no search for now, guess I'll just get used to that.

Meaningful enough. Searching for the exact tag was possible with added spaces . And it was handy for finding out how often some tag has been used, useful when making alias/implication suggestions.

Though primarily, I've used it for artist tags. Some users have a habit of constantly replacing Japanese nicks with their own transliterations and such. Which is a problem when you only know the original nick. History search was a quick way to tracking down where the posts have been moved.

Within a specific niche it is meaningful, but the field doesn't have anything related to when the tag was added or removed, so everyone looking for -female or +female is wasting their time, since the field only has the full tag list for that change without any notion of what changed. So added and still present on the post are the same thing within the search. It's a total mess, and the UI is heavily misleading about what the real results actually are.

Updated by anonymous

KiraNoot said:
It needs to be entirely redesigned from the ground up to fix the problems with it. There isn't anything I can do right this moment to make it faster with how it was designed. Not to mention that it doesn't even return meaningful results for what you search for.

I have no idea how this shit works, but would it be possible to make it take a little longer before it times out? Just so we're not having to send the same request over and over again.

Updated by anonymous

I've found that setting the results limit (&limit=? in the URL) to a lower number (100 is the default) seems to at least somewhat combat this problem. You're obviously going to get fewer results but time-outs seem much less frequent or completely absent.

Updated by anonymous

darryus said:
I've found that setting the results limit (&limit=? in the URL) to a lower number (100 is the default) seems to at least somewhat combat this problem. You're obviously going to get fewer results but time-outs seem much less frequent or completely absent.

Some database tuning took place recently and that likely has improved the situation a bit. However, setting lower limits can actually make things worse. The default of 100 is pretty safe. To put it in perspective, the limit takes place after everything else and is quite literally just discarding collected data, so it takes the least amount of time{in the nanosecond range). Everything else is what makes it take a long time.

Updated by anonymous

  • 1