Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
17 changed files
with
394 additions
and
191 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blazek This is a nice change, but I've noticed that expanding out schemas from a PostGIS database in the browser is now very slow. Previously schemas would expand instantly, it now seems like the whole database is re-queried every time a schema is expanded...
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally all schemas were populated with layers when a database was expanded. It did not seem optimal to me because there may be many schemas which user does not want to expand. I changed it so that when the database is expanded it only creates list of schemas and schema layers are populated when the schema is expanded.
So yes, it takes more time to expand a schema, but it should never take significantly (yes one query is repeated, but it is single query which should be fast) more time to expand database + expand schema than it took before and usually (if there are other schemas) it should take less time (because slow is the layer type query which is launched for every layer). Can you post approximate times (before/after the commit database / schema) ? Now you can also find "Children created in ### ms" in debug output.
BTW, I know that it is crashing on refresh of WMS with sublayers, I hope to fix that soon.
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blazek - hmmm, that does sound like the correct approach. I'll do some benchmarks and see if there's actually a problem here.
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blazek I don't think this is working correctly - looking at the code, QgsPostgresConn::supportedLayers always queries every layer in the database, it's not limited to a specific schema. This means that QgsPGConnectionItem::createChildren() first iterates over every table to get a unique list of schemas in the database, and then QgsPGSchemaItem::createChildren() also refetches every table and then subsequently filters out any which aren't in the current schema. So for both the initial listing of schemas and for every schema expansion we are querying every database table.
This could be dramatically improved if QgsPGConnectionItem::createChildren() only queried the pg_catalog.pg_namespace table, and then QgsPostgresConn::getTableInfo was modified to accept a schema and only fetched info for tables under that particular schema.
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blazek - here's a (broken) proof of concept fix: nyalldawson@3987e6d
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nyalldawson QgsPostgresConn::supportedLayers() makes list of all tables but in single query. The slow QgsPostgresConn::retrieveLayerTypes() is called from QgsPGSchemaItem::createChildren(), but only for layers in current schema ( if ( layerProperty.schemaName != mName ) continue; ).
Does your proof (why broken?) make really difference in time? But it is surely improvement to add scheme support to QgsPostgresConn::getTableInfo(), you mean const QString schema = QString() to keep compatibility? Just push when ready please, thanks.
Anyway, we should maybe add all schemas to connection (even those without (geometry) layers) to allow to drag layers to an empty schema?
BTW, there are other interesting issues which I don't know how to solve, for example, if a server is slow and connection fails and the user deletes the connection during createChildren(), QgsPostgresConn will continue to open credentials dialog. I have no idea how to stop QgsPostgresConnPool::instance()->acquireConnection() once it was called.
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blazek my "fix" causes a crash when adding layers from the browser. I'm not familiar with that code area, so it makes me nervous that there's not unintended side effects of this change (are QgsPGSchemaItem and QgsPGLayerItem only used for the browser?). But... it's a dramatic difference on my server. Without this change the initial population of schemas takes around 10 seconds, and expanding each schema takes about the same time again. With this change both operations are nearly instant. I'd imagine that this change would also make a huge difference for remote postgres connections too...
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nyalldawson It's crashing without the fix as well, you can push and I'll fix the crash in browser later.
40bb180
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nyalldawson Quick fix in 9fbcc7e, hopefully works. I have to review items hierarchy once more.