paulo matadr wrote:
> teste=# \d cliente_fone
> Table "cadastro.cliente_fone"
> Column | Type | Modifiers
> ------------------------+---------------- -------------+------------------------
> cfon_id | integer | not null
> clie_id | integer | not null
> cfon_cdddd | character(2) |
> cfon_nnfone | character varying(9) |
> cfon_nnfoneramal | character varying(4) |
> cfon_icfonepadrao | smallint |
> fnet_id | integer | not null
> cfon_tmultimaalteracao | timestamp without time zone | not null default now()
> cfon_nmcontato | character varying(50) |
> Indexes:
> "cliente_fone_pkey" PRIMARY KEY, btree (cfon_id)
> Foreign-key constraints:
> "cliente_fone_clie_id_fkey" FOREIGN KEY (clie_id) REFERENCES cliente(clie_id) ON UPDATE RESTRICT ON DELETE
RESTRICT
> "cliente_fone_fnet_id_fkey" FOREIGN KEY (fnet_id) REFERENCES fone_tipo(fnet_id) ON UPDATE RESTRICT ON DELETE
RESTRICT
I don't see anything there that would account for the growth either.
However, I forgot to check one thing with you when I asked for the table
sizes: Do you have any associated toast table, and if so how big is that?
You can find out with a query like:
select oid, relname, reltype, reltuples, relpages, relpages*8 AS size_kb
from pg_class where relname = 'TABLENAME'
OR oid = (SELECT reltoastrelid FROM pg_class
WHERE relname = 'TABLENAME');
It's quite possible that your table, including associated TOAST data, is
actually much bigger than you think it is.
--
Craig Ringer