-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick Bower wrote: > We're considering using Postgresql for storing gridded metadata - each point > of our grids has a variety of metadata attached to it (including lat/lon, > measurements, etc) and would constitute a record in Postgresql+Postgis. > > Size-wise, grids are about 4000x700 and are collected twice daily over say 10 > years. As mentioned, each record would have up to 50 metadata attributes > (columns) including geom, floats, varchars etc. > > So given 4000x700x2x365x10 > 2 billion, is this going to be a problem if we > will be wanting to query on datetimes, Postgis lat/lon, and integer-based > metadata flags? > > If however I'm forced to sub-sample the grid, what rule of thumb should I be > looking to be constrained by? > > Thanks for any pointers, Nick Tablespaces and table partitioning will be crucial to your needs. I'm not sure if you can partition indexes, though. And too bad that compressed bit-map indexes have not been implemented yet. For indexes with high "key cardinality", they save a *lot* of space, and queries can run a lot faster. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/Ur7S9HxQb37XmcRAsKLAKDnC36QSzRuaedSsXe+rQp3fbDbOgCfSwlQ ip2em5mEmXF45kek2rHKJvw= =uqTK -----END PGP SIGNATURE-----
