Feature request
When a search is typed into the search box on the Query Log or Long-term Data/Query Log pages, wait for a short time, say 3 seconds, after typing has stopped before updating search results in the list below.
Rationale
At the moment each keystroke immediately updates the list below. If that list contains a few hundred or thousand entries then each keystroke locks the interface up for a few seconds while the updated search takes place. This is very noticeable in the Long-term Data Query Log if all results are shown, where delays can be 10+ seconds per keystroke.
A partial workaround is to leave the dropdown set to "Show 10 entries". This then filters the entire list very quickly. However if there are many hits and the dropdown is changed to Show All entries" in order to see them, then modifying the search term gets back to the original behaviour described. since All entries are now being displayed.
Example
A list with 10,000 entries. I want to search for stackoverflow. Type: s ... (wait a few seconds for list to update)... t ...(wait a few seconds)... a ...(wait a few seconds) and so on. The wait gets shorter as the search whittles down the results in realtime. It's the first 2-4 characters perhaps that have the most delay. If I make a typo I have to wait for the update, then delete the typo, wait again, and enter the correct character and wait again. While the updates are taking place the entire web UI is unresponsive. It can take upwards of 30 seconds to enter the string sta in this example.
With a short delay the behaviour would change as follows. Type stack, and the string can be typed without anything happening below. Then, after say 3 seconds, the search takes place. This allows the search to be modified, edited, typos corrected, etc without each keystroke forcing an update and wait.
It's no big deal, but if it's easy to tweak the script (is it queries.js?) to add a short pause before searching, I thought I'd mention it here in case it's of interest, especially in orgs who may have many thousands of entries and want to dig into the logs (though they may well be using the OS rather than the web interface). It may be of more interest for busy homes with lots of devices and who rely on the web interface as their primary means of interacting with their data.
Thanks as ever for your work on Pi-hole