fix: removed unnecessary full table scan to check relevant point count#690
Conversation
|
Hi @Jonsen94, First thank you for the effort in making reitti better. Really appreciate it. If I understand your fix correctly we are clamping the returned value of the query to maxPoints. Or do I get that wrong? Then, would it not be better to just skip the whole sql when maxPoints is provided? I do not think something will break if we provide maxPoints more than there are points for the next query. Unfortunately, you didnt know it, but this method will be removed in the next release and I do not plan in providing one before. I switched it so all datapoints will be streamed to the map and we do not need to do this anymore. |
|
Yes, as we only care whether there are more than max points in the area+timeframe or not we can clamp the counting and thus allowing postgres to return early without scanning the rest of the table. I do not think that we can skip the query completely as we use the result to decide if we want to return all points in the timeframe or do sampling (if we have more points than we allow via max points). But if the method will be removed with the next release, this change will not really help. If all datapoints will be streamed to the map, will this lead to issues on big timescales/map areas? I myself will not be available during the next week. |
|
There is no estimate yet for the next release, i am currently replacing (or actually this is finished) the main map. In my testing it works really nice with more than a million points, but the load is transferred to the frontend. The backend will only have to load 1000 points at a time before they are dispatched. As soon as I have finished the different map modes I will optimize it there. |
|
Thanks for merging :) Finally back from my holiday. Happily awaiting the new update! |
Just a minor performance gain.
Tested on my underpowered nas with ~4.5M data points when selecting all points:
~500ms for the count statement before
~30ms after the fix