Skip site navigation (1) Skip section navigation (2)

Re: Vacuum-full very slow

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-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                      
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-04-27 13:21:04
Subject: Re: Avoiding unnecessary reads in recovery
Previous:From: Alvaro HerreraDate: 2007-04-27 13:16:42
Subject: Re: Avoiding unnecessary reads in recovery

pgsql-general by date

Next:From: Carlos MorenoDate: 2007-04-27 13:27:49
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
Previous:From: Jorge GodoyDate: 2007-04-27 13:01:54
Subject: Re: Converting time to float

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group