[postgis-devel] [raster] Memory management and IO concerns

[Bryce L Nordgren]

On Wed, Jun 29, 2011 at 9:01 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

> > You've hit on the point I was trying to make. A single row (or a single
> raster) is
> > guaranteed to be rectangular, has no gap, no overlap and it is always
> > guaranteed that interlopers will fail to break my nice image. The
> standard way
> > to provide efficient I/O and memory management for these perfect rasters
> is to
> > provide the tiling services that people from a raster background have
> come to
> > expect.
>
> At the price of not being able to support other tile arrangement.
>
>
They're complementary, not conflicting.  I'm advocating a more efficient way
to access information in an individual raster after the correct row has been
located with the existing infrastructure.


> We could go further and provide fast subtile retrieving for big tiles but
> I'm not sure it is necessary to go that far.
>

Exactly what I'm proposing, and that's exactly how it's complementary.  This
provides not just increased speed, but increased memory efficiency too.


> I would put this as a future refactoring/optimization of the rt_api
> internals. But you will first have to justify why storing small tiles does
> not fulfill your application needs.
>

Ahh, so you're open to the possibility and wouldn't fight me if I wanted to
fund this. :)


Hum no... Both ST_SetValue(newrast, 1, x, y, newval) are O(1) operations...
> Since every raster has its own georeference and you can easily derive the
> memory location of the requested pixel value in O(1). Take also into account
> the fact that those two rasters are already loaded.
>

The index calculations are clearly O(1). DETOASTing and RETOASTING the
entire raster are each O(N^2) operations, I presume, and this happens with
every call to ST_SetValue()/ST_Value(). Unless I'm not understanding this
toast thing. See Paul's msg:

http://postgis.refractions.net/pipermail/postgis-devel/2011-June/013882.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110629/7cc4e045/attachment.html>