[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