-
Notifications
You must be signed in to change notification settings - Fork 41
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
Kart is slow when using PostGIS working copy #968
Comments
Hi @SrNetoChan Can you run the commands with increased verbosity |
I have tried
No extra information was provided. |
Apologies for the awkwardness of getting some logging output.
All this script does is turn on extra debug output, and then run This should produce quite a lot of output that could help diagnose the issue, mostly SQL queries. Feel free to attach it here, or let me know if you have any trouble running the script. |
Thanks for the script. It works well. Below there's only the begining part of the log, as it seems to repeat for all the layers under tracking since there are a lot of tables, it takes a while. Full log is here: I am probably missing something, so please ignore if this is a non-sense suggestion. The SQL queries seems to first search for all the tables under tracking, and then for each table found, check if it's in the Suggestion: Since there are triggers on all tracked tables to change the table status in the It also seems that even if the target table is not is in the kart_state table , it still proceeds to do an extra query (that I don't fully understand what it does but seems to try to see the differences between working copy changes and the last commit). ** Suggestion**: Since the table name is not in the kart_state table, shouldn't this be avoided? Meanwhile, thanks for your great work, let me know if I can be of any help.
|
The issue is that the Having only just started thinking about this, I don't have a solution right now. Possible improvements could be:
|
Ah, that makes sense. I was not aware that kart would be able to track changes to the tables structure. That's nice! The If this table could somehow be tracked internally (for kart) for the all the tables under version control, with one single query it would be possible to return a list of tables that suffered structure changes. Then only tables in kart_status and with the structure changes would need to actually check the differences. Again, just an idea, as I have no idea how kart works internally. SELECT * |
Describe the bug
I find kart quite slow when using a PostGIS working copy on a remote server.
My QGIS project have many layers +100 all tracked by kart. But it feels snappy enough when I am zooming, panning editing.
I noticed that the _kart_track table stores the tables and features that suffered changes. Nevertheless, even if I only have changed one table, when asked to see the global working changes or running git status. it takes lot's of time to return an answer.
I wonder what queries are being made to the database at that point and if they could be improved somehow or if there are indexes missing somewhere.
Output
Add the output you're seeing to help explain your problem.
**Version Info **
Kart v0.14.2, Copyright (c) Kart Contributors
» GDAL v3.6.3; PROJ v9.2.0; PDAL v2.5.6
» PyGit2 v1.12.1; Libgit2 v1.6.4; Git v2.38.1; Git LFS v3.3.0
» SQLAlchemy v1.4.45; pysqlite3 v2.6.0/v3.40.1; SpatiaLite v5.0.1; Libpq v15.0.3
Executed via helper, SID=452462 PID=452740
The text was updated successfully, but these errors were encountered: