<br><br><div class="gmail_quote">On Tue, Jun 28, 2011 at 10:08 AM, Mark Cave-Ayland <span dir="ltr"><<a href="mailto:mark.cave-ayland@siriusit.co.uk">mark.cave-ayland@siriusit.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 24/06/11 00:04, Bryce L Nordgren wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there a way to encapsulate "DETOAST" logic such that only the raster<br>
header, a specific band header, and the corresponding band data are<br>
loaded? I'd hate to have to write that logic in more than one function.<br>
And the correlary, can you DETOAST different slices as they're needed or<br>
do you have to load everything upfront? (e.g., load image blocks?)<br>
</blockquote>
<br></div>
Unfortunately I don't think so; I think you'd have to disable TOAST on the raster column and then implement some kind of custom grid compression scheme to avoid having to decompress an entire raster as part of the PG_DETOAST_DATUM() call. But someone else who knows better may be able to correct me here.<br>
</blockquote><div><br>If this is correct, the size limitation on in-database rasters is not the full 32Tb (or whatever) of the Postgresql backend, but the amount of memory (and swap) present on the server, minus whatever is being used by other processes (including other raster operations) on the same server. Truly large images will have to be out-database rasters which GDAL understands how to "chunk"/"block"/"tile". Unless I'm missing something. <br>
<br>If there is a way to "DETOAST" only part of a raster, it may be possible to develop a GDAL driver which understands the Postgresql server-side "SLICE"ing.<br><br>Actually, I've already hit something else which may be a more stringent limit: when trying to load a single band of a Landsat image (not tiled, loaded as a single raster), I got an out of memory error. I assumed this was in the parser, as the SQL file generated by raster2pgsql.py used a single "INSERT" statement to plop in the entire 64Mb binary image. I hadn't thought of this before, but large rasters may need to be loaded via many "ST_SetRasterDataBlock" calls rather than one INSERT.<br>
<br>Bryce<br><br><br></div></div>