| From: | Daniel Kalchev <daniel(at)digsys(dot)bg> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Clift <justin(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Brain dump: btree collapsing |
| Date: | 2003-02-13 08:23:58 |
| Message-ID: | 200302130823.h1D8NwY18153@dcave.digsys.bg |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>Bruce Momjian said:
>
> This brings up one item it would be nice to address at the same time.
> It would be nice if VACUUM FULL would be able to compress the actual
> index file and return unused space to the operating system. REINDEX
> does this, but I was thinking of something a little lighter that could
> be done automatically as part of VACUUM FULL. If we can do that, it
> would make consistent behavior for vacuum and heap/index files.
Since lazy VACUUM exists, I always wondered why VACUUM FULL doesn't run
REINDEX on a table where significant number of deleted tuples. VACUUM knows
those numbers - I always run REINDEX on larger tables that had huge number of
index entries deleted during VACUUM...
Daniel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Brown | 2003-02-13 09:09:14 | Re: [HACKERS] PostgreSQL Benchmarks |
| Previous Message | Daniel Kalchev | 2003-02-13 08:16:36 | Re: Brain dump: btree collapsing |