<div dir="ltr"><p style="box-sizing:inherit;margin:1em 0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">Hi Richard,</p><p style="box-sizing:inherit;margin:1em 0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial"> one guy said that once:</p><p style="box-sizing:inherit;margin:1em 0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial"><span style="color:rgb(91,40,88);font-family:OpenSans,sans-serif;font-size:16px;font-style:italic">There are only two hard things in Computer Science: cache invalidation and naming things.</span><br></p><p class="gmail-quote-attribution" style="box-sizing:inherit;margin:1em 0px;padding:0px;border:0px;outline:0px;font-size:16px;vertical-align:baseline;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;color:rgb(91,40,88);font-family:OpenSans,sans-serif;font-style:italic">-- Phil Karlton</p>Joke apart, current situation is not good for sure, especially for WFS which has a cache, and that should be handled better in transactional WFS-T use cases. <div><br><div>For Postgres, we recently hit a problem, not related to big datasets, but to very laggy database and network, that led the client to switch back to WFS, with a its cache giving an impression of reactive application. </div><div>Cache invalidation seems especially complicated currently when you have some business logic inside the database (triggers), and even more when using Transaction groups, where any action is commited on the fly in the database. It starts to be tricky keeping in sync the snapping index cache and the attribute table cache only for features concerned by the transaction. <br></div><div>Matthias also pointed out that we don't have very specific cache invalidation signals for attribute table, and we should have some to be able to invalidate only the features concerned by a transaction (for instance). </div><div><br></div><div>So I think we must go that way, at least to consolidate current features, but I think should be handled very seriously by a group of dev knowing each parts of the application. That is an excellent candidate topic for Madeyra. </div><div><br></div></div><div>Régis</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-06 11:05 GMT+01:00 Richard Duivenvoorde <span dir="ltr"><<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Working with a rather large dataset (16M timebased points), I have trouble working with this in QGIS, using both the Postgis-provider OR the WFS-provider.<br>
<br>
As data is properly indexed, retrieving a selected area is fine.<br>
<br>
BUT as soon as you try to use the attribute table, I-tool or for example the TimeManager, QGIS stalls.<br>
<br>
I think(!) because apparently both providers are requesting all data again from their datasource, sometimes even ignoring the current extent (WFS).<br>
<br>
While, it seems more appropriate to 'just use what you already have': the dataprovider/QGIS already has all features (both geom + attributes in case of WFS for example), so WHY should it request all data again (data-freshness?)?<br>
<br>
Are others having this problems too?<br>
<br>
Could adding a 'Caching-option' for the QgsDataProvider be a reasonable/viable option:<br>
- if 'data caching' is enabled, the data will be retrieved only once (per extent probably). So showing the Attribute table, I-tool info, or using TimeManager/Query should be relatively easy/fast as the features are locally (or in memory) cached.<br>
- as soon as you want 'fresh' data you disable the caching temporarily, and new data will be requested (as it is doing now apparently).<br>
<br>
Or am I missing something (I see there is an option for attributetable caching...)?<br>
<br>
Not sure about other countries, but here in NL governmental institutes start serving huge dataset more and more, either as WMS/WCS/WFS services, or more and more as REST/GeoJSON services.<br>
<br>
Anybody has some insights ideas about this?<br>
<br>
Regards,<br>
<br>
Richard Duivenvoorde<br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a></blockquote></div><br></div>