| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Listmail <lists(at)peufeu(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Vacuum-full very slow |
| Date: | 2007-04-27 13:18:08 |
| Message-ID: | 20070427131808.GE4645@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Martijn van Oosterhout wrote:
> On Thu, Apr 26, 2007 at 12:13:13AM +0200, Listmail wrote:
> > VACUUM FULL is slow because it plays with the indexes...
> > CLUSTER is slow because it has to order the rows...
>
> And:
> VACUUM FULL has to seek/read/write all over the disk to get it's job
> done.
> CLUSTER can scan through the table linearly a few times and write out
> the result.
> Now it's true that sorting large files involves overflowing to disk,
> but that path has been pretty well optimised.
Hmm, no, CLUSTER doesn't scan the table linearly; it uses an indexscan,
so it also needs seek/read/seek/read/write.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Carlos Moreno | 2007-04-27 13:27:49 | Re: Feature Request --- was: PostgreSQL Performance Tuning |
| Previous Message | Jorge Godoy | 2007-04-27 13:01:54 | Re: Converting time to float |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-04-27 13:21:04 | Re: Avoiding unnecessary reads in recovery |
| Previous Message | Alvaro Herrera | 2007-04-27 13:16:42 | Re: Avoiding unnecessary reads in recovery |