Re: VACUUM FULL versus CLUSTER ON

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
Cc: Sven Willenberger <sven(at)dmv(dot)com>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org>
Subject: Re: VACUUM FULL versus CLUSTER ON
Date: 2006-07-07 16:57:51
Message-ID: 874pxtmjxs.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Csaba Nagy <nagy(at)ecircle-ag(dot)com> writes:

> I won't know for sure, but I guess the least downtime you would get by
> not dropping the indexes before the delete, but do a reindex after it.
> Then cluster on the primary key...
>
> My reasoning (correct me if I'm wrong): the deletion speed won't be
> affected by the indexes, I think deletions don't touch the indexes at
> all.

That's true, more or less. I think there's a small hit actually as queries set
the hint bit and the pages have to be flushed.

As long as you're just deleting and not inserting or updating

> The REINDEX command recreates all indexes at once, I think it needs
> only one full table scan.

No, each index build has to do its own full scan. It wouldn't save much
anyways not to, where would you store the tuples in the meantime? And why
would this temporary storage place be any faster than scanning the original
table?

--
greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sven Willenberger 2006-07-07 17:26:14 Re: VACUUM FULL versus CLUSTER ON
Previous Message Joshua D. Drake 2006-07-07 16:55:32 Re: VACUUM FULL versus CLUSTER ON