Обсуждение: Res: Res: Res: Archive files growth!!!

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

paulo matadr wrote:
> see  results:
>   oid  |   relname    | reltype | reltuples | relpages | size_kb
> -------+--------------+---------+-----------+----------+---------
>  16506 | cliente_fone |   16507 |    341130 |     3345 |   26760


OK, so there is no TOAST table either. I am out of ideas. It's not
indexes, it's not toast table contents, it's not some action being done
by a trigger, so why is so much WAL logging data generated for these
inserts?

Does anybody have any ideas about what's happening, or any suggestions
about how to find out?

--
Craig Ringer