<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
Using the field calculator either from the attribute table or from
main window with the attribute table closed both takes too long to
be useful. Not the actual calculation, but the saving of the
edits. To be clear: I originally used the update expression bar to
update the selection, but all three methods take too long to save.<br>
<br>
I'm currently experiencing the issue on localhost, so it's not the
network connection.<br>
<br>
I have a workaround by reducing the number of joins (or finding
the join that is causing the problem) and rewriting the definition
of the view, however, it would be interesting if it could be
solved in QGIS. <br>
<br>
thanks for any help/thoughts,<br>
Janneke<br>
<br>
<br>
On 29/11/2015 18:50, Matthias Kuhn wrote:<br>
</div>
<blockquote cite="mid:565B1EAD.4030606@opengis.ch" type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
Hi,<br>
<br>
Short explanation for the difference:<br>
<br>
* If you do it with the db manager you send a request to the
database "please update all records with this SQL".<br>
* If you do it with the field calculator, QGIS requests all
records, evaluates the expression locally and sends dozens of
update statements.<br>
<br>
That said, the time is pretty long anyway. I am sure that there's
potential for improvement also with local evaulation. But this can
be limited by several factors:<br>
<br>
How long does it take with the field calculator and the attribute
table closed?<br>
(There have been some bottlenecks for updating the table in the
past)<br>
How long is the network latency (a simple "ping [server]" gives
already a good hint)<br>
<br>
Best<br>
Matthias<br>
<br>
<div class="moz-cite-prefix">On 11/29/2015 04:42 PM, Janneke van
Dijk wrote:<br>
</div>
<blockquote cite="mid:565B1CE6.8070907@gmail.com" type="cite">
<div class="moz-cite-prefix">Hi Nyall,<br>
<br>
Tested it with 12.1.1, that doesn't make a difference as far
as I can tell (40 minutes now). I tested the view without the
many joins for lookup values (it had about 13 joins and
reduced it to 4), which made it take around 15 seconds, which
would be acceptable. I haven't yet tested if it may be one
specific join that causes the behaviour or that it is the
number of joins.<br>
<br>
I'm still curious to understand what the difference is between
the update statement in the db manager and the way the data
are updated from the attribute table. Could it be that the
update via db manager only needs to 'calculate' the joins
once, where the update via the attribute table has to loop
through all the selected features, 'calculating' the joins for
every record that needs to be saved? If that is the case,
would there be a way to bypass this behaviour (by using the
original where clause for making the selection maybe)?<br>
<br>
greetings,<br>
Janneke<br>
<br>
On 28/11/2015 01:42, Nyall Dawson wrote:<br>
</div>
<blockquote
cite="mid:CAB28AsgudE0Vr1oc9fV7_NNRU3XNDM_w6e8wm2xPScenvzWwcw@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On 27 Nov 2015 10:18 PM, "Janneke van Dijk" <<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:janneke.qgis@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:janneke.qgis@gmail.com">janneke.qgis@gmail.com</a></a>>
wrote:<br>
><br>
> Dear list,<br>
><br>
> I have an updateable spatial view in Postgres loaded
into QGIS 2.10. When I update 6999 records in this view in
the db manager with the following statement:<br>
> update v_prepare_assessment_id SET districtid = 8 where
locationid > 13000 and locationid < 20000<br>
> it takes 2.7 seconds to complete.<br>
><br>
> When I open the attribute table, select the same
records, then use the update bar in the top to update the
districtid to 8, using 'update selected' , then save edits,
it takes more than 10 minutes (after which I closed the
project).<br>
><br>
> Doing the same update directly on the attribute table
of the underlying postgres table works nicely (takes about 3
seconds) after save edits.<br>
><br>
> Does anyone know why the update via the attribute table
on the view takes so long as to be unusable, while the db
manager works nicely with the view? Seeing that working
directly on the underlying table from the attribute table
works well too it's seems to be a combination of the
attribute table approach with an updateable view that seems
to cause the issue.<br>
><br>
> Thanks for any thoughts on the matter,</p>
<p dir="ltr">Please try with 2.12.1 or the current nightly
snapshots.</p>
<p dir="ltr">I made a change since 2.12 which may have
improved this already.</p>
<p dir="ltr">Nyall<br>
><br>
> Janneke<br>
> _______________________________________________<br>
> Qgis-user mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a><br>
> List info: <a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
> Unsubscribe: <a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a></p>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Qgis-user mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
List info: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
Unsubscribe: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Matthias Kuhn
OPENGIS.ch - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.opengis.ch">https://www.opengis.ch</a>
Spatial • (Q)GIS • PostGIS • Open Source</pre>
</blockquote>
<br>
</body>
</html>