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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
