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

Improve attribute table performance #21008

Closed
qgib opened this issue Jun 9, 2015 · 6 comments
Closed

Improve attribute table performance #21008

qgib opened this issue Jun 9, 2015 · 6 comments

Comments

@qgib
Copy link
Contributor

qgib commented Jun 9, 2015

Author Name: Paolo Cavallini (@pcav)
Original Redmine Issue: 12926

Redmine category:attribute_table


Loading a large (pg) table requires the loading of all records. This is a real performance killer, and effectively prevents the use of layers with millions of records.
Moreover, even when selection Show only selected in Options, and selecting a few records, apparently all records are read, so this does not speed up.
This beaviour is changed from 1.8 to 2.0. In older versions if you show only selection or show only object visible in map extent qgis was faster. With newer version it has to read all the table data every time it is opened.
See also #19023


Related issue(s): #19023 (relates), #20496 (relates)
Redmine related issue(s): 10619, 12318


@qgib
Copy link
Contributor Author

qgib commented Jun 9, 2015

Author Name: Jürgen Fischer (@jef-n)


  • tracker_id was changed from 1 to 2
  • subject was changed from Loading attribute table very slow to Improve attribute table performance
  • priority_id was changed from Normal to High

@qgib
Copy link
Contributor Author

qgib commented Nov 30, 2015

Author Name: Alessandro Pasotti (@elpaso)


Here is an attempt to speed things up: #2518

@qgib
Copy link
Contributor Author

qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • easy_fix was configured as 0

@qgib
Copy link
Contributor Author

qgib commented May 10, 2017

Author Name: Regis Haubourg (@haubourg)


Some work has been done here and seems to really improve things: [[https://github.com//pull/4230]]

Some other improvements seem possible again with joined fields.


  • description was changed from Loading a large (pg) table requires the loading of all records. This is a real performance killer, and effectively prevents the use of layers with millions of records.
    Moreover, even when selection Show only selected in Options, and selecting a few records, apparently all records are read, so this does not speed up.
    This beaviour is changed from 1.8 to 2.0. In older versions if you show only selection or show only object visible in map extent qgis was faster. With newer version it has to read all the table data every time it is opened.
    See also Attribute table 'Show features visible on map' option does not speed up loading of large postgis table #19023
    to Loading a large (pg) table requires the loading of all records. This is a real performance killer, and effectively prevents the use of layers with millions of records.
    Moreover, even when selection Show only selected in Options, and selecting a few records, apparently all records are read, so this does not speed up.
    This beaviour is changed from 1.8 to 2.0. In older versions if you show only selection or show only object visible in map extent qgis was faster. With newer version it has to read all the table data every time it is opened.
    See also Attribute table 'Show features visible on map' option does not speed up loading of large postgis table #19023

  • status_id was changed from Open to In Progress

@qgib
Copy link
Contributor Author

qgib commented Mar 7, 2018

Author Name: Paolo Cavallini (@pcav)


The two PR are closed. Should we close this as well?
Any automatic performance testing?


  • status_id was changed from In Progress to Feedback

@qgib
Copy link
Contributor Author

qgib commented Mar 7, 2018

Author Name: Giovanni Manghi (@gioman)


Still slow for large tables if compared to other (gis) software. Better than in the past anyway.


  • resolution was changed from to fixed/implemented
  • status_id was changed from Feedback to Closed

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

No branches or pull requests

1 participant