From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Thoughts on maintaining 7.3 |
Date: | 2003-10-05 03:13:34 |
Message-ID: | 20031005031334.GB20484@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Do we move empty index pages to the end before truncation during vacuum
> > full?
>
> No. You'd be better off using REINDEX for that, I think. IIRC we have
> speculated about making VAC FULL fix the indexes via REINDEX rather than
> indexbulkdelete.
I can't agree with that idea. Imagine having to VACUUM FULL a huge
table. Not only it will take the lot required to do the VACUUM in the
heap itself, it will also have to rebuild all indexes from scratch. I
think there are scenarios where the REINDEX will be much worse, say when
there are not too many deleted tuples (but in that case, why is the user
doing VACUUM FULL in the first place?). Of course there are also
scenario where the opposite is true.
I wonder if VACUUM FULL could choose what method to use based on some
statistics.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-10-05 03:17:09 | Re: Thoughts on maintaining 7.3 |
Previous Message | Tom Lane | 2003-10-04 23:44:40 | Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ... |