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

[Stephen Frost]

Frank,

* Frank Warmerdam (warmerdam at pobox.com) wrote:
> 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?  

No, if we use the side-table, then the 31-bit typmod would just be an
uninteresting auto-increment for every different combination of values
provided by the user.

> How is this side table better than having non-view style of raster_columns
> table?

The side-table would only hold unique combinations, making it very
likely to be much smaller than a table with an entry for every table in
the database.  For example, my geometry_columns table on one of my
databases has 31,135 records in it, with all of 15 unique
coord_dimension, srid, type combinations.  This is due in part to my use
of partitioning in this database, but that's an extremely common
technique for dealing with large data sets (this happens to be the TIGER
2007 shapefile data loaded into PG).  I would expect that to be true for
raster_columns too, but I could be wrong since I havn't dealt with them
to the extent that others have.

Also, by using typmod, users could do:

create table my_table (
  my_key		integer,
  my_geom		geometry(4269,2,'POINT'),
  my_attrib		text
);

And have it 'just work'.  They could also do:

create table my_table_copy as select * from my_table;

and have it 'just work'.  They could also do:

create view just_mine as select * from my_table WHERE my_attrib = 'me'; 

and have it 'just work'.

pg_dump'ing a given schema would result in output like above, which
could be loaded into another database, again, where it would 'just
work'.  No more having to deal with AddGeometryColumn() or hacking on
the table directly for things like views.

> Would there be one of these side tables per schema?

No.

> 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.

No problem, I'm doing my best to address your concerns, but honestly,
this is still mainly concept with no real code behind it.  I'd just like
to make sure we don't go down a road that makes moving to that difficult
later.

>> 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.

That wasn't my intent for this, no.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090313/850d8cf6/attachment.sig>