| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
| Cc: | Kevin Hunter <hunteke(at)earlham(dot)edu>, 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 20:53:47 |
| Message-ID: | 20080813205347.GB4672@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tino Wildenhain escribió:
> Which makes me think if the solution would be to just run CLUSTER under
> the hood when VACUUM FULL is requested. Would that introduce any
> other problems?
The difference is that CLUSTER requires double the disk space in table +
indexes. VACUUM FULL has no such requirement.
A possibly approach would be to do an ANALYZE (to have fresh stats about
dead tuple density), and do a CLUSTER if the density is too high.
There has been talk about rewriting VACUUM FULL anyway; it's complex
code and it introduces extra complications in other parts of code that
would be otherwise unneeded, e.g. HOT. I have no idea what a rewritten
VACUUM FULL would look like, though.
Another thing we should do in this area is rewrite CLUSTER to use a
seqscan + sort instead of indexscan when the heap/index order
correlation is low.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bartels, Eric | 2008-08-13 20:57:06 | Re: Postgres eats all memory |
| Previous Message | Raymond O'Donnell | 2008-08-13 20:48:23 | Re: PostgreSQL and SVN - help me... |