| From: | Kevin Hunter <hunteke(at)earlham(dot)edu> |
|---|---|
| To: | 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 17:16:03 |
| Message-ID: | 48A316D3.7070608@earlham.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
At 12:53p -0400 on Wed, 13 Aug 2008, Martijn van Oosterhout wrote:
> On Wed, Aug 13, 2008 at 12:41:41PM -0400, Kevin Hunter wrote:
>> Roughly, VACUUM simply reclaims/frees disk space, while VACUUM FULL
>> additionally reorganizes disk usage. I'm still don't know *why* this
>> leads to index bloat, however, just that it does. I must defer that
>> explication to a Postgres guru.
>
> Because VACUUM FULL needs to move stuff around in the table which means it
> need to mess around with the indexes (adding new entries). Ordinary
> VACUUM only needs to delete stuff so doesn't cause anywhere near as
> many problems.
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?
Or, failing that, what's the reason to not issue a REINDEX CONCURRENTLY
automatically after a VACUUM FULL (or something to that effect)?
Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Ross | 2008-08-13 17:29:29 | Re: Column alias in where clause? |
| Previous Message | Martijn van Oosterhout | 2008-08-13 17:12:12 | Re: Column alias in where clause? |