Re: Updating a very large table

On Freitag 24 April 2009 Scott Marlowe wrote:
> Also, if you're doing the select into thing, you can drop the indexes
> then recreate them.  Usually also faster on a big table being
> reordered.
> CLUSTER always rebuilds all indexes on the table.  There's no point
> doing a REINDEX afterward or dropping indexes first.

But once you did the first CLUSTER, subsequent ones are pretty quick. In
dbmail (a mail system using postgres as mailstore), this boostet
performance a lot, as data is ordered on disk the way it is read, which
helps a lot with caching. And it works automatically. I run it once a
week since some time, it takes a fraction of the backup time to CLUSTER
most tables (except some minor tables where order doesn't matter).

mfg zmi
--
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4