Il 27/02/2014 03:17, Martin Dobias ha scritto:
Paolo: make sure you have render caching turned on. Deactivating (and
activating again) a layer should be immediate. Of course, if you pan
the map or zoom in/out, everything will be re-rendered.
Hi Martin,
thanks for this. It helps, but my
Hi Paolo
On Mon, Mar 3, 2014 at 7:18 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Il 27/02/2014 03:17, Martin Dobias ha scritto:
Paolo: make sure you have render caching turned on. Deactivating (and
activating again) a layer should be immediate. Of course, if you pan
the map or zoom
Martin, maybe render caching should be turned/forced on by default on qgis
master builds right now so there can be a higher of ppl using it and
reporting possible regressions? If it's now smooth and problem-free
following mtr merge, it can be left on by default for final 2.4 release.
On 3 Mar 2014
Hi, just tested with cache enabled and multi cpu .
Memory do not stop increasing on each new rendering, from 240 Mo starting
with no upper limit.
With cache disabled, I also face memory growth, but very slow, and probably
related to only some drawing actions (labels or raster? not sure).
Hi all.
Why exactly is using PostGIS so painful on a slow connection? I
understand that loading time is long, but I do not know why editing or
zooming should be so slow.
Any explanation? Better yet: any solution?
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS PostGIS courses:
Hi Paolo,
Explanation:
Zooming and editing require loading of data (we don't cache much data
locally)
Solution (partly):
* Activating server side simplification for such layers gives a
noticeable speed boost here.
* Get a faster network ;)
Best
Matthias
On Wed 26 Feb 2014 11:15:22 AM CET,
On 02/26/2014 11:30 AM, Matthias Kuhn wrote:
Hi Paolo,
Explanation:
Zooming and editing require loading of data (we don't cache much data
locally)
Solution (partly):
* Activating server side simplification for such layers gives a
noticeable speed boost here.
* Get a faster network ;)
* I
Il 26/02/2014 11:31, Matthias Kuhn ha scritto:
Zooming and editing require loading of data (we don't cache much data
locally)
I see: wouldn't it be better to do it?
* Activating server side simplification for such layers gives a
noticeable speed boost here.
just tried, I do no see a
Le 2014-02-26 11:30, Matthias Kuhn a écrit :
Solution (partly):
* Activating server side simplification for such layers gives a
noticeable speed boost here.
* Get a faster network ;)
What about requesting and using Tiny WKT when possible ? :)
Hi,
As far as I know libpq does not support compression.
There is a lengthy discussion on libpq compression at
http://postgresql.1045698.n5.nabble.com/libpq-compression-td5712541.html
Andreas
Am 26.02.2014 10:15, schrieb Paolo Cavallini:
Hi all.
Why exactly is using PostGIS so painful on a
Il 26/02/2014 13:29, Andreas Neumann ha scritto:
Hi,
As far as I know libpq does not support compression.
There is a lengthy discussion on libpq compression at
http://postgresql.1045698.n5.nabble.com/libpq-compression-td5712541.html
Some of the slowness is understandable, some not really,
It sounds like the PostGIS connection provider could use some optimisations.
The Oracle provider had/has a few which are being resolved (thanks
Jurgen!), but it does first require identifying what queries are being run
during what actions. If you have access, watch what queries are running on
On Wed, Feb 26, 2014 at 02:52:28PM +0100, Paolo Cavallini wrote:
Il 26/02/2014 13:29, Andreas Neumann ha scritto:
Hi,
As far as I know libpq does not support compression.
There is a lengthy discussion on libpq compression at
On Wed, Feb 26, 2014 at 12:43:10PM +0100, Paolo Cavallini wrote:
Il 26/02/2014 11:31, Matthias Kuhn ha scritto:
Zooming and editing require loading of data (we don't cache much data
locally)
I see: wouldn't it be better to do it?
* Activating server side simplification for such
Some of the slowness is understandable, some not really, e.g. why
deactivating a layer in the legend should require time?
that's a case where the render-cache should work. When deactivating a
layer, QGIS will just redraw all remaining visible layers. In case the
render-cache was active it would
Il 26/02/2014 15:39, Sandro Santilli ha scritto:
I'd suggest to file a ticket for each case of that sort.
Thanks.
Would it be appropriate pointing out that deactivating a layer should
not load any data from the server? Seems reasonable to me.
All the best.
--
Paolo Cavallini - www.faunalia.eu
Il 26/02/2014 17:25, Matthias Kuhn ha scritto:
Fair enough to at least look at what's currently being done with the
requested data and evaluating if it's appropriate (in every case) IMHO.
That means, please open a ticket and add information about the executed
queries if possible.
Hi Andreas
On Wed, Feb 26, 2014 at 9:48 PM, Andreas Neumann a.neum...@carto.net wrote:
Some of the slowness is understandable, some not really, e.g. why
deactivating a layer in the legend should require time?
that's a case where the render-cache should work. When deactivating a
layer, QGIS
18 matches
Mail list logo
