[postgis-devel] RE: WKTRaster news from the Toronto CodeSprint?

[Frank Warmerdam]

Stephen Frost wrote:
> Basically, you would be joining the PG catalog table entry with the
> side-table to pull the attributes you need, in that case.  In the case
> where the information is encoded into the typmod, there would be helper
> functions to translate the typmod into the different pieces of
> information which are stored in it.

Stephen,

So the "side table" would hold the subset of the "raster_columns" columns
that cannot be encoded in the 31 bits of typemod information?  Stuff like
extents, pixel size, block size, and such?  How is this side table
better than having non-view style of raster_columns table?  Would there be
one of these side tables per schema?

I would like to stress I'm not really a sophisticated postgres user/developer.
I'm just a raster guy trying to ensure I have the information I need so if
others can refine things to avoid pitfalls that will be great.

> I doubt very much that performance would be bad, since we would index
> the side-table appropriately, of course, but I'm all for doing
> performance testing to ensure there is no regression.

I was primarily concerned that the extents might be computed on the fly
by a scan of the columns themselves.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent