From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Stephen Frost" <sfrost(at)snowman(dot)net> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Rethinking user-defined-typmod before it's too late |
Date: | 2007-06-19 18:47:25 |
Message-ID: | 1182278845.6855.335.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-06-19 20:09:44 | Re: Maximum reasonable bgwriter_delay |
Previous Message | Simon Riggs | 2007-06-19 18:28:34 | Re: Maximum reasonable bgwriter_delay |