Re: [PATCHES] Arrays of Complex Types

Awhile back I wrote:
> I did some tests just now to determine the total number of catalog
> entries associated with a simple table definition. Assuming it has
> N user columns of built-in types (hence not requiring pg_depend entries
> for the datatypes), I count

> 1 pg_class entry for the table itself
> 1 pg_type entry for the rowtype
> N + 6 pg_attribute entries for the user and system columns
> 2 pg_depend entries (type -> table and table -> namespace)
> 2 pg_shdepend entries (ownership of table and type)

> Of course this goes up *fast* if you need a toast table, indexes,
> constraints, etc, but that's the irreducible minimum.

> Generating an array rowtype would add three more catalog entries to this
> (the array pg_type entry, a pg_depend arraytype->rowtype link, and
> another pg_shdepend entry), which isn't a huge percentage overhead.
> Obviously if we wanted to trim some fat here, getting rid of the
> redundant pg_attribute entries for system columns would be the first
> place to look.

BTW, in the array patch as just committed, I was able to get rid of the
pg_shdepend entries for a table rowtype (when it's not a free-standing
composite type) and for an array type; instead they indirectly depend
on the owner of the parent table or element type respectively. So the
net increase from 8.2 is only one catalog entry (we save one existing
pg_shdepend entry for the rowtype, and then add a pg_type entry for the
array type and a pg_depend entry to link it to the rowtype).

regards, tom lane