Re: Composite types or composite keys?

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