Skip to content
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

Postgis: cache information about enum fields #9219

Merged
merged 2 commits into from
Feb 21, 2019

Conversation

elpaso
Copy link
Contributor

@elpaso elpaso commented Feb 20, 2019

This is called several times and can slow down substantially
the opening of the attribute table.

Partially fixes #21303 (down from ~30 to ~6 seconds on a remote
connection)

The remaining ~4 seconds (compared to ~2 seconds in 2.18) are due
to the check for enums and provider-side constraints, that were
not implemented in 2.18.

See: QgsEnumerationWidgetFactory::fieldScore and the call to
enumValues for details, fieldScore is called several times
because QgsAttributeTableModel::loadAttributes is also
called multiple times and it queries for widget configuration
all the times.

This is called several times and can slow down substantially
the opening of the attribute table.

Partially fixes qgis#21303  (down from ~30 to ~6 seconds on a remote
connection)

The remaining ~4 seconds (compared to ~2 seconds in 2.18) are due
to the check for enums and provider-side  constraints, that were
not implemented in 2.18.

See: QgsEnumerationWidgetFactory::fieldScore and the call to
enumValues for details, fieldScore is called several times
because QgsAttributeTableModel::loadAttributes is also
called multiple times and it queries for widget configuration
all the times.
@elpaso elpaso merged commit e42c6a3 into qgis:master Feb 21, 2019
@elpaso elpaso deleted the bugfix-21303-postgis-slow-table-open branch February 21, 2019 07:32
@gioman
Copy link
Contributor

gioman commented Feb 21, 2019

@elpaso brillant! tested it and at least in the use case where I first noticed the problem now it become usable again.

@gioman
Copy link
Contributor

gioman commented Feb 21, 2019

any chance to have this backported?

@elpaso
Copy link
Contributor Author

elpaso commented Feb 21, 2019

I think that the same considerations from #9203 apply here.

@gioman
Copy link
Contributor

gioman commented Feb 21, 2019

I think that the same considerations from #9203 apply here.

ok, I understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants