-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subsequent selections kill QGIS ui performance #41366
Comments
O yeah, confirmed here too on master. |
I'm going to try Hotspot as Nyall was showing in his bugfixing video: Mmm, using Hotspot appimages (both latest and nightly) crash as soon as I try to attach to running QGIS. |
Fetching features by id (the ids of the previously selected features). |
@elpaso is that needed to be able to (optionally) merge the new selection to the old one? So you think adding an index on the id (if available) would help? Will try it now... AND another question to me: why does this behaviour only show when you change the way to do the selection, and NOT when you keep the same? |
No, it won't help for the reason you mention below and I'm pretty sure GPKG already has an index on the fid.
Sorry, I'm busy on other issues and I only had time for a quick debug run yesterday evening, the only evidence I have so far is that it gets stuck on retrieving every single feature individually by id, because of the existing selection. I'll see if I can have a closer look later. |
I'll take a look if you want @elpaso? |
Yes, please 😃 |
field) when the attribute form is opened. This is incredibly expensive, yet only required in a very very small corner case (field is from a joined layer without the upsert on edit capabilities). Refine logic to avoid the scan wherever we can. Fixes qgis#41366 Fixes qgis#36863
field) when the attribute form is opened. This is incredibly expensive, yet only required in a very very small corner case (field is from a joined layer without the upsert on edit capabilities). Refine logic to avoid the scan wherever we can. Fixes qgis#41366 Fixes qgis#36863 (cherry picked from commit c661359)
field) when the attribute form is opened. This is incredibly expensive, yet only required in a very very small corner case (field is from a joined layer without the upsert on edit capabilities). Refine logic to avoid the scan wherever we can. Fixes qgis#41366 Fixes qgis#36863 (cherry picked from commit c661359)
field) when the attribute form is opened. This is incredibly expensive, yet only required in a very very small corner case (field is from a joined layer without the upsert on edit capabilities). Refine logic to avoid the scan wherever we can. Fixes #41366 Fixes #36863 (cherry picked from commit c661359)
When creating a selection in a rather large dataset, the first time is pretty fast.
BUT if you then change the way of selecting (for example change from select by Value to select by Expression) THEN Qgis stalls.
How to Reproduce
Is QGIS at that moment 'unselecting' the earlier selection? Or... what is it that QGIS is busy with?
Running 3.16 or master on Linux
The text was updated successfully, but these errors were encountered: