The composite type is clean design, but it does not help performance at all.
First of all, float translates to float8 a.k.a. double precision in Postgres. You are building on a misunderstanding.
The real data type occupies 4 byte (not 8). It has to be aligned at multiples of 4 bytes.
Measure actual sizes with pg_column_size().
SQL Fiddle demonstrating actual sizes.
The composite type real3d occupies 36 bytes. That's:
23 byte tuple header
1 byte padding
4 bytes real x
4 bytes real y
4 bytes real z
---
36 bytes
If you embed that into a table, padding may have to be added. On the other hand the header of the type can be 3 byte smaller on disk. Representation on disk is typically a bit smaller than in RAM. Doesn't make a lot of difference.
More:
Table layout
Use this equivalent design to reduce row size substantially:
Column | Type | Modifiers
---------------+--------------------------+---------------------------------
id | bigint | not null default nextval(...
creation_time | timestamp with time zone | not null default now()
edition_time | timestamp with time zone | not null default now()
user_id | integer | not null
project_id | integer | not null
location_x | real | not null
location_y | real | not null
location_z | real | not null
radius | real | not null default 0
skeleton_id | integer | not null
confidence | smallint | not null default 5
parent_id | bigint |
editor_id | integer |
Test before and after to verify my claim:
SELECT pg_relation_size('treenode') As table_size;
SELECT avg(pg_column_size(t) AS avg_row_size
FROM treenode t;
More details:
