You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whenever there is a result set (SELECT * FROM earthquakes) with many (~23000) tuples the switch from the "Task Description" tab to the "Results" tab is very slow (multiple seconds).
However, when the same query is run with the "Results" tab open, there is no freezing.
The text was updated successfully, but these errors were encountered:
OK, thanks.
I will have to investigate this one. I'll have to dig down into the data workflow of the application, which always needs some time. I need to figure out first, if this is a caching problem, a network problem, due to UI components or my very own code...
I just can say, that the application is, nevertheless, not really robust enough (yet) to handle these large data amounts. Sorry for the inconvenience.
As far as I can tell, this only happens for more than a few hundred rows. If the data amount is the problem, then a re-design of some internal would be necessary. Thus I will put a wontfix label on this one, and postpone the implementation to 1.0.0
Whenever there is a result set (SELECT * FROM earthquakes) with many (~23000) tuples the switch from the "Task Description" tab to the "Results" tab is very slow (multiple seconds).
However, when the same query is run with the "Results" tab open, there is no freezing.
The text was updated successfully, but these errors were encountered: