On Fri, 2007-06-15 at 15:01 -0400, Stephen Frost wrote: > But we'd only get 31 bits of room to encode that into. I'm not sure if > that's enough. :( At the moment there's three columns we're talking > about in the side-table: > SRID (integer) > TYPE (varchar(30)) > DIMENSIONS (integer) > > Now, the type is a small enumerated set, and we can probably limit > dimensions to a few bits (maybe one for 2d/3d, but we might have some > other cases...), and still be following the OGC standard, but I don't > think there are any restrictions on SRID beyond '32 bit integer'. As > such, I'm not sure if we can encode it all directly into 31 bits (which > would obviously be preferred to a side-table with each case we come > across being enumerated in it). Then again, at the *moment*, anyway, > the SRIDs we have only go up to about 32,000, so we could dedicate 16 > bits to it and probably be alright.
This is for type/column definitions, so you'd only have a problem if you had more than 2 billion defined combinations of (SRID, TYPE, DIMENSIONS) in the database. Admittedly this would need to cope with all user defined typmods created during SQL execution e.g. X::typmod(A, B, C), but ISTM that would never realistically be a problem. The typmod function could cache the top ten combinations etc.. > Any chance of this being increased? Obviously would like to avoid the > side-table, if possible. If you had more than 2 billion permutations you'd definitely want that in a table. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
