Re: Composite types or composite keys?

On 16 Nov 2013, at 3:01 am, Merlin Moncure  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