<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body>
    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">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <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">
        <meta http-equiv="Context-Type" content="text/html; ">
        <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 class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
List info: <a 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 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 class="moz-txt-link-freetext" href="https://www.opengis.ch">https://www.opengis.ch</a>
Spatial • (Q)GIS • PostGIS • Open Source</pre>
  </body>
</html>