| From: | "Eugene M(dot) Zheganin" <emz(at)norma(dot)perm(dot)ru> |
|---|---|
| To: | Thierry Missimilly <THIERRY(dot)MISSIMILLY(at)BULL(dot)NET> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Full vacuuming of BIG tables takes too long |
| Date: | 2003-05-22 12:37:01 |
| Message-ID: | 94981743421.20030522183701@norma.perm.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Hello Thierry,
Thursday, May 22, 2003, 5:45:26 PM, you wrote:
TM> Hi,
TM> I don't have a solution but :
TM> 1) Is your system spending time in Wait I/O, while vacuum analyze is running
TM> ?
Almost no. During fist 30 mins summary I/O (iostat 1) is 20/25
megs/sec, then only 3-5 megs/sec. the "i/o wait" counters in cpu
activity are not too high.
TM> Perhaps, you can save time by incrising I/O throughput.
I.e. to use SCSI-HDD ? 8)) May be. But I stall hope tha the problem
can be solved by increasing memory/tuning initialization parameters...
TM> 2) In the alternative dump/recreate/restore, do you recreate the Foreign Key
TM> ? This step takes long time (depending of your Database schema). I have try
TM> this scenario :
TM> Dump data / Drop Foreign Key / Truuncate Tables / restore / Recreate the
TM> Foreign Key
TM> The step Recreate FK takes 2 times the four first steps.
I don't use foreign keys. Only primary keys. There is only 3 tables in
that db. 99% of space is taken by one table.
--
Best regards,
Eugene mailto:emz(at)norma(dot)perm(dot)ru
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ernest E Vogelsinger | 2003-05-22 13:20:13 | Q: Structured index - which one runs faster? |
| Previous Message | Bruno Wolff III | 2003-05-22 12:31:05 | Re: SECURITY |