[Qgis-developer] split features takes a LONG time over network

Matthias Kuhn matthias.kuhn at gmx.ch
Wed Jan 30 22:56:37 PST 2013


Hi William,

On 01/30/2013 07:37 PM, William Kyngesburye wrote:
> Some more info: editing attributes in the attributes table is fast, even in quick succession, but applying a field calculator to a selection again appears to be downloading the whole table.
The attribute table does cache features [1], but the cache is internal 
to the attribute table, so the calculator is not able to make use of it.
My current work includes separating the feature cache from the attribute 
editor. This won't immediately speed up the calculator but it may be 
included there as well.
A couple of days ago, there already was a discussion in the "new vector 
api" thread on this list about caching and before starting to work on 
this change this discussion would better be brought up again, to decide 
on some more details (e.g. vectorlayercache vs. dataprovidercache).l

[1] There is a setting about how many, defaults to 10000. In case the 
capability "feature by id" is disabled it will even cache all
>
> In all cases (today's and original issue) saving changes back to the database is fast.
>
> On Jan 28, 2013, at 4:23 PM, William Kyngesburye wrote:
>
>> On Jan 28, 2013, at 4:10 PM, Vincent Picavet wrote:
>>
>>> Hi William,
>>>
>>>> On Jan 28, 2013, at 3:05 PM, William Kyngesburye wrote:
>>>>> I'm trying to split a selected line feature in a postgis database on the
>>>>> network (not local machine).  The database layer is almost 4GiB (10M
>>>>> records) and is spatially indexed.
>>> Do you have a primary key defined on your PostGIS table ?
>>>
>> yes
>>
>>> Vincent
>>>
>>>>> The feature is selected, it's not very large and I am zoomed to see about
>>>>> half of it.  It took about a half hour to split, and during that time
>>>>> was downloading a constant stream from the postgis server.  I'm guessing
>>>>> it looked at every feature in the database.
>>>>>
>>>>> bug? (didn't see anything in the tracker)  lack of optimization?  maybe
>>>>> it was fixed in trunk?  Continuing to edit this database will be
>>>>> impractical as it is in 1.8.
>>>>>
>>>>>
>>>>> QGIS 1.8, OS X
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
>
> "I ache, therefore I am.  Or in my case - I am, therefore I ache."
>
> - Marvin
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
Matthias



More information about the Qgis-developer mailing list