On 16 Nov 2013, at 3:01 am, Merlin Moncure <mmonc...@gmail.com> wrote: > > Well, here are the downsides. Composite types: > *) are more than the sum of their parts performance-wise. So there is > a storage penalty in both the heap and the index > *) can't leverage indexes that are querying only part of the key > *) will defeat the implicit 'per column NOT NULL constraint' of the primary > keys
Thanks, I didn’t see any of those - I was thinking that they were like pseudo tables or column templates. > *) are not very well supported in certain clients -- for example JAVA. > you can always deal with them as text, but that can be a headache. > > ...plus some other things I didn't think about. If you can deal with > those constraints, it might be interesting to try a limited > experiment. The big upside of composite types is that you can add > attributes on the fly without rebuilding the index. Test carefully. I’ll give it a try - I might stick to using plain or inherited tables for the main storage and then experiment with composite types for functions and other aggregate tables that are used internally. Cheers, Tony -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
