Re: New VACUUM FULL

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New VACUUM FULL
Date: 2010-01-05 01:53:01
Message-ID: 603c8f071001041753u66a2e9ud101940680cf55cc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 4, 2010 at 8:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> Changes required to remove it are at least these places
>>>
>>> * most of vacuum.c
>>> * visibility checks
>>> * heap tuple flags and xvac
>>> * nontransactional validation
>>> * minor points and follow up in >7 files, >12 places
>
>> Doesn't sound trivial.
>
> The above is a vast overstatement of the problem.  Simon is not only
> talking about removing VACUUM FULL, he's talking about removing every
> trace that it ever existed, eg deleting support for MOVED_OFF/MOVED_IN
> tuple status flags.  We are *not* doing that, not now nor in the
> foreseeable future.  As long as we have any ambition of having in-place
> upgrade from pre-8.5 we have to handle the MOVED status bits the same as
> we do now.
>
> AFAICS, ripping out most of the guts of vacuum.c is about all that's
> likely to happen for 8.5.

Well, it sounds like Simon is saying we shouldn't do even that much.

Frankly, I'm less concerned with what we're not doing than with what
we are doing. From my point of view this VACUUM FULL patch is the
most important patch on the table, because it seems that before we can
release (1) it has to be committed and then (2) some more work has to
be done and committed. We can decide later exactly how far we want to
take it and whether to do what you're suggesting here or not; right
now I think we should try to keep the focus on moving the current
patch forward, since based on what has been said so far, that seems to
be on the critical path for 8.5.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-05 02:20:42 Re: pgsql: Get rid of the need for manual maintenance of the initial
Previous Message Robert Haas 2010-01-05 01:35:50 Re: ECPG DESCRIBE [OUTPUT] support