Обсуждение: Unreasonable size of table pg 8.2.5

Поиск
Список
Период
Сортировка

Unreasonable size of table pg 8.2.5

От
Henrik
Дата:
Hello list,

I have a table with 135 rows and it still takes up about 360MB with
only small columns. Details below.

db=# vacuum full tbl_archive;
VACUUM
db=# select * from
pg_size_pretty(pg_total_relation_size('tbl_archive'));
  pg_size_pretty
----------------
  360 MB
(1 row)

db=# select * from pg_size_pretty(pg_relation_size('tbl_archive'));
  pg_size_pretty
----------------
  16 kB
(1 row)


Looks like we have a very bloated index.
After reindex
db=# select * from
pg_size_pretty(pg_total_relation_size('tbl_archive'));
  pg_size_pretty
----------------
80 kB
(1 row)

I thought that reindex should not be necessary in 8.2.5? This is not a
big tabel but what I can see is that we have many small updates.
Cheers,
Henke

db=# \d tbl_Archive;
                                                 Table
"public.tbl_archive"
            Column            |            Type
|                          Modifiers
-----------------------------+-----------------------------
+--------------------------------------------------------------
  pk_archive_id               | bigint                      | not null
default nextval(('archive_seq_id'::text)::regclass)
  archive_name                | character varying(255)      |
  archive_backup_type         | character(1)                |
  archive_size                | bigint                      | not null
default 0
  fk_share_id                 | bigint                      |
  archive_complete            | boolean                     | not null
default false
  fk_job_id                   | bigint                      |
  archive_date                | timestamp without time zone | not null
default now()
  archive_nmb_files           | integer                     | not null
default 0
  archive_nmb_folders         | integer                     | not null
default 0
  archive_nmb_file_exceptions | integer                     | not null
default 0
Indexes:
     "tbl_archive_pkey" PRIMARY KEY, btree (pk_archive_id)
     "tbl_archive_idx" btree (archive_complete)
     "tbl_archive_idx1" btree (fk_share_id)
     "tbl_archive_idx2" btree (fk_job_id)
Check constraints:
     "tbl_archive_chk" CHECK (archive_backup_type = 'F'::bpchar OR
archive_backup_type = 'I'::bpchar)
Foreign-key constraints:
     "tbl_archive_fk" FOREIGN KEY (fk_share_id) REFERENCES
tbl_share(pk_share_id) ON UPDATE CASCADE ON DELETE SET NULL
     "tbl_archive_fk1" FOREIGN KEY (fk_job_id) REFERENCES
tbl_job(pk_job_id) ON DELETE SET NULL


Re: Unreasonable size of table pg 8.2.5

От
Bill Moran
Дата:
Henrik <henke@mac.se> wrote:
>
> Hello list,
>
> I have a table with 135 rows and it still takes up about 360MB with
> only small columns. Details below.
>
> db=# vacuum full tbl_archive;
> VACUUM
> db=# select * from
> pg_size_pretty(pg_total_relation_size('tbl_archive'));
>   pg_size_pretty
> ----------------
>   360 MB
> (1 row)
>
> db=# select * from pg_size_pretty(pg_relation_size('tbl_archive'));
>   pg_size_pretty
> ----------------
>   16 kB
> (1 row)
>
>
> Looks like we have a very bloated index.
> After reindex
> db=# select * from
> pg_size_pretty(pg_total_relation_size('tbl_archive'));
>   pg_size_pretty
> ----------------
> 80 kB
> (1 row)
>
> I thought that reindex should not be necessary in 8.2.5?

VACUUM FULL tends to bloat indexes, which is one of the reasons that it's
not recommended for regular maintenance.

Use plain VACUUM instead.  If you feel the need to run a VACUUM FULL, always
do a REINDEX afterward.

Even still, there are apparently some corner cases around that cause index
bloat.  If it turns out that you've found one, you may want to document it
so the developers can look into possible solutions.

--
Bill Moran
http://www.potentialtech.com

Re: Unreasonable size of table pg 8.2.5

От
Henrik
Дата:
6 dec 2007 kl. 15.25 skrev Bill Moran:

> Henrik <henke@mac.se> wrote:
>>
>> Hello list,
>>
>> I have a table with 135 rows and it still takes up about 360MB with
>> only small columns. Details below.
>>
>> db=# vacuum full tbl_archive;
>> VACUUM
>> db=# select * from
>> pg_size_pretty(pg_total_relation_size('tbl_archive'));
>>  pg_size_pretty
>> ----------------
>>  360 MB
>> (1 row)
>>
>> db=# select * from pg_size_pretty(pg_relation_size('tbl_archive'));
>>  pg_size_pretty
>> ----------------
>>  16 kB
>> (1 row)
>>
>>
>> Looks like we have a very bloated index.
>> After reindex
>> db=# select * from
>> pg_size_pretty(pg_total_relation_size('tbl_archive'));
>>  pg_size_pretty
>> ----------------
>> 80 kB
>> (1 row)
>>
>> I thought that reindex should not be necessary in 8.2.5?
>
> VACUUM FULL tends to bloat indexes, which is one of the reasons that
> it's
> not recommended for regular maintenance.
>
> Use plain VACUUM instead.  If you feel the need to run a VACUUM
> FULL, always
> do a REINDEX afterward.
I usually only do normal vacuum but its good to know that reindex
should be ran after vacuum full.
>
>
> Even still, there are apparently some corner cases around that cause
> index
> bloat.  If it turns out that you've found one, you may want to
> document it
> so the developers can look into possible solutions.
>
I maybe have an idea why its get this big but I'll do some more
testing first!
Thanks,
Henke
> --
> Bill Moran
> http://www.potentialtech.com
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>               http://archives.postgresql.org/