From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hervé Piedvache <herve(at)elma(dot)fr> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Why memory is not used ? Why vacuum so slow ? |
Date: | 2004-01-02 15:51:13 |
Message-ID: | 5930.1073058673@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
=?iso-8859-15?q?Herv=E9=20Piedvache?= <herve(at)elma(dot)fr> writes:
> and I have also saw that the full vacuum for pg_atribute seems
> to be so slow ... more than 1 min for 7256 tupples ? Is this is normal ?
> INFO: --Relation pg_catalog.pg_attribute--
> INFO: Pages 119: Changed 0, reaped 1, Empty 0, New 0; Tup 7256: Vac 0, Keep/
> VTL 0/0, UnUsed 3, MinLen 128, MaxLen 128; Re-using: Free/Avail. Space
> 14664/504; EndEmpty/Avail. Pages 0/1.
> CPU 0.00s/0.00u sec elapsed 0.08 sec.
> INFO: Index pg_attribute_relid_attnam_index: Pages 21082; Tuples 7256:
> Deleted 0.
> CPU 0.83s/0.13u sec elapsed 59.32 sec.
> INFO: Index pg_attribute_relid_attnum_index: Pages 5147; Tuples 7256: Deleted
> 0.
> CPU 0.26s/0.03u sec elapsed 8.79 sec.
You're suffering from index bloat (21000 pages in an index for a
119-page table!?). Updating to 7.4 would probably fix this, but
if that's not practical consider reindexing pg_attribute.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-01-03 02:18:45 | Re: Tuning Techniques To Avoid? |
Previous Message | Tom Lane | 2004-01-02 15:45:07 | Re: Very slow update + not using clustered index |