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

field calculator update is very slow #19884

Closed
qgib opened this issue Nov 12, 2014 · 6 comments
Closed

field calculator update is very slow #19884

qgib opened this issue Nov 12, 2014 · 6 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Expressions Related to the QGIS expression engine or specific expression functions

Comments

@qgib
Copy link
Contributor

qgib commented Nov 12, 2014

Author Name: Gavin Fleming (@gubuntu)
Original Redmine Issue: 11631
Affected QGIS version: 2.6.0
Redmine category:field_calculator


I select a small number of records in a layer with a few hundred thousand records and use the field calculator to update them. What used to be (or should be) an almost instant operation takes many seconds. It is longer than I would take to update them manually in the table.

@qgib
Copy link
Contributor Author

qgib commented Nov 12, 2014

Author Name: Giovanni Manghi (@gioman)


do you see any difference if you use the FC with the table of attributes open or closed?


  • category_id was configured as Field calculator
  • status_id was changed from Open to Feedback

@qgib
Copy link
Contributor Author

qgib commented Nov 13, 2014

Author Name: Gavin Fleming (@gubuntu)


540000 road LineString records, 8 core i7 with SSD, 8GB RAM

no difference updating 17 records whether table is open or not, both 30s.

Opening the table just adds another looong wait (how can this be minimised?).

@qgib
Copy link
Contributor Author

qgib commented Nov 13, 2014

Author Name: Giovanni Manghi (@gioman)


Gavin Fleming wrote:

540000 road LineString records, 8 core i7 with SSD, 8GB RAM

no difference updating 17 records whether table is open or not, both 30s.

Opening the table just adds another looong wait (how can this be minimised?).

postgis?

@qgib
Copy link
Contributor Author

qgib commented Nov 13, 2014

Author Name: Gavin Fleming (@gubuntu)


local PostgreSQL 9.3, PostGIS 2.1

@qgib
Copy link
Contributor Author

qgib commented Nov 13, 2014

Author Name: Giovanni Manghi (@gioman)


Gavin Fleming wrote:

540000 road LineString records, 8 core i7 with SSD, 8GB RAM

no difference updating 17 records whether table is open or not, both 30s.

Opening the table just adds another looong wait (how can this be minimised?).

I'm really not lucky as it doesn't seem I'm able to replicate any of the issues you file :)

In this case:

  • I downloaded the OSM UK roads shape, 3 million features and imported it into a local postgis installation (9.3, Linux, 4 cores, 8gb ram and SSD).

  • selected a few tens of records/features (20/30) and updated an attribute.

  • repeated the above after selecting ~200k features

results:

in both cases the update operation, after clicking the "ok" button in the field calculator, takes a few seconds (eventually what can be surprising is the fact that the time it takes does not seems to differ much between a few records selected and a lot of records selected).

In the past we had issues when updating (or creating) fields with the FC and at the same time having the table of attributes open. I remember also another similar issue that was related to the number of features that were visible the moment the FC was used. In both cases fixes/patches has been applied and the situation is much better now.

Opening a 3 million table of attributes table here take ~25 seconds from shapefile and ~40 from postgis.

Unchecking the "select at id" option when loading the postgis layer make a little faster the operation, ~30 seconds, but in this case there may be a bug as the operation is done 2 times (to notice is necessary to open a postgis table of at least 80/100k features). Jurgen, is this right?

To make faster opening large table is usually used the "show features visible on map" option, but this is known to be bugged for postgis layers.

@qgib
Copy link
Contributor Author

qgib commented May 21, 2015

Author Name: Giovanni Manghi (@gioman)


closing for lack of feedback.


  • resolution was changed from to worksforme
  • status_id was changed from Feedback to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Expressions Related to the QGIS expression engine or specific expression functions labels May 25, 2019
@qgib qgib closed this as completed May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Expressions Related to the QGIS expression engine or specific expression functions
Projects
None yet
Development

No branches or pull requests

1 participant