From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
Cc: | "PostgreSQL General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 7.3.1 takes long time to vacuum table? |
Date: | 2003-02-19 17:23:24 |
Message-ID: | 12288.1045675404@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> writes:
> In fact, my colleague has just done a test with SELECT..INTO on our
> dev
> version and it compacted 600Mb -> 400Mb in just 40s(!). We then did
> a
> vacuum full on the same original 600Mb table which is still going
> after
> 20mins.
>>
>> Are there indexes on the original table? If so, this isn't a fair
>> comparison.
> Fair point actually, I should have made it a better comparison. The
> source table has 5 btree indexes, each on a bigint field. However, it
> has taken just under a minute to recreate the first! The vacuum full on
> the original 600Mb table has finished after 100mins, so it looks as if I
> used the SELECT..INTO method could be up and done in 10mins! I can
> continue recreating the other indexes to get a proper final time
> comparison if you are interested?
Yeah. Also, I don't suppose you made that a VACUUM VERBOSE and kept the
output? It'd be interesting to see which stages took the most time.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2003-02-19 17:23:48 | Re: techdocs broken again. |
Previous Message | Mark Cave-Ayland | 2003-02-19 17:10:40 | Re: 7.3.1 takes long time to vacuum table? |