| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Kevin Hunter <hunteke(at)earlham(dot)edu> |
| Cc: | Joao Ferreira <joao(dot)miguel(dot)c(dot)ferreira(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres General List <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: automatic REINDEX-ing |
| Date: | 2008-08-13 18:44:06 |
| Message-ID: | 20080813184406.GD2958@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Aug 13, 2008 at 01:16:03PM -0400, Kevin Hunter wrote:
> Hmm. I get the reorganization bit, but so what? Since VACUUM FULL
> already has an exclusive lock, what prevents it from updating the
> indexes in-place to point to the new physical disk location? Why does
> it need to create extra bloat?
AIUI, people know VACUUM FULL sucks and that in the cases where it
really helps CLUSTER is faster anyway and doesn't have the index
problems. The TODO list reference several discussions on the topic.
> Or, failing that, what's the reason to not issue a REINDEX CONCURRENTLY
> automatically after a VACUUM FULL (or something to that effect)?
Or how about not doing VACUUM FULL at all. It's not a command that
should be run regularly in most situations.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Hunter | 2008-08-13 19:04:41 | Re: automatic REINDEX-ing |
| Previous Message | Joost Kraaijeveld | 2008-08-13 18:15:20 | In-place conversion of type bool |