Thank you for your response! You have proposed some new and interesting ideas.
I understand that saving huge amounts of data would be both time-consuming and memory intensive. So bearing in mind this limitation I think that these feature proposals would apply:
- If query runs longer than "X" seconds results will be added to history
- Query results are always added to history an "N" amount back in time, however if the query result is a "Z" amount of rows long then only the top first "F" number of rows are saved.
As a general rule saving query results should be fast and efficient. If possible once the user starts query execution the fetched query results will already start to be saved in history before the query execution finishes, else if this is not possible, the query results are saved after the query execution.
In addition I think the user should be blocked from executing queries during the process when the results are saved so the user cannot stack saving processes where some of the processes in the stack have not yet finished saving. This idea were there cannot be simultaneous saving processes can slow down the user because he has to wait for the saving to finish before executing the next query. Of course once a query execution display its results, the user takes some time to scroll through the results and therefore the query results saving process can save the results during this short period of time. One of the questions important in deciding how this feature is implemented is: What is the average time it takes for results to be saved on a typical disk drive?
The "ideal" (unsure if it is possible) way of saving query results history is to always save the results in the background and simultaneously, without the user knowing. Therefore if for example the user has configured that 5 results should be saved in time, then the order of the query executions would govern which 6th result should be scrapped. Having this simultaneous approach a query results saving process could still be in process when it passes further than the maximum history which should be saved, therefore the process should be killed in this case. Of course these are some ideas, you decide which you think is best.
- If user hits some shortcut - results will be added to history as well
I agree on the above statement and I think this is a must for this feature.
Regards to the guard option, well, I think it is not bad but it should be kept as a last resort because there is not concept of history there anyways and like me 😁 the user might have got used to selecting yes.