gistVacuumUpdate

Started by Nonamealmost 14 years ago5 messages
#1Noname
yamt@mwd.biglobe.ne.jp

hi,

gistVacuumUpdate was removed when old-style VACUUM FULL was removed.
i wonder why.
it was not practical and REINDEX is preferred?

anyway, the removal seems incomplete and there are some leftovers:
F_TUPLES_DELETED
F_DELETED
XLOG_GIST_PAGE_DELETE

YAMAMOTO Takashi

#2Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Noname (#1)
Re: gistVacuumUpdate

On 13.01.2012 06:24, YAMAMOTO Takashi wrote:

hi,

gistVacuumUpdate was removed when old-style VACUUM FULL was removed.
i wonder why.
it was not practical and REINDEX is preferred?

anyway, the removal seems incomplete and there are some leftovers:
F_TUPLES_DELETED
F_DELETED
XLOG_GIST_PAGE_DELETE

Hmm, in theory we might bring back support for deleting pages in the
future, I'm guessing F_DELETED and the WAL record type were left in
place because of that. Either that, or it was an oversight. It's also
good to have the F_DELETED/F_TUPLES_DELETED around, so that new versions
don't get confused if they see those set in GiST indexes that originate
from an old cluster, upgraded to new version with pg_upgrade. For that
purpose, a comment explaining what those used to be would've been
enough, though.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

#3Noname
yamt@mwd.biglobe.ne.jp
In reply to: Heikki Linnakangas (#2)
Re: gistVacuumUpdate

hi,

On 13.01.2012 06:24, YAMAMOTO Takashi wrote:

hi,

gistVacuumUpdate was removed when old-style VACUUM FULL was removed.
i wonder why.
it was not practical and REINDEX is preferred?

anyway, the removal seems incomplete and there are some leftovers:
F_TUPLES_DELETED
F_DELETED
XLOG_GIST_PAGE_DELETE

Hmm, in theory we might bring back support for deleting pages in the
future, I'm guessing F_DELETED and the WAL record type were left in
place because of that. Either that, or it was an oversight. It's also
good to have the F_DELETED/F_TUPLES_DELETED around, so that new versions
don't get confused if they see those set in GiST indexes that originate
from an old cluster, upgraded to new version with pg_upgrade. For that
purpose, a comment explaining what those used to be would've been
enough, though.

the loop in gistvacuumcleanup to search F_DELETED pages seems too expensive
for pg_upgrade purpose.
(while it also checks PageIsNew, is it alone worth the loop?)

i'm wondering because what gistVacuumUpdate used to do does not seem to
be necessarily tied to the old-style VACUUM FULL.
currently, no one will re-union keys after tuple removals, right?

YAMAMOTO Takashi

Show quoted text

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

#4Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Noname (#3)
Re: gistVacuumUpdate

On 18.01.2012 23:38, YAMAMOTO Takashi wrote:

i'm wondering because what gistVacuumUpdate used to do does not seem to
be necessarily tied to the old-style VACUUM FULL.
currently, no one will re-union keys after tuple removals, right?

Right. I believe gistVacuumUpdate needed an AccessExclusiveLock, so now
that VACUUM FULL is gone, there is no good moment to do it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

#5Jaime Casanova
jaime@2ndquadrant.com
In reply to: Heikki Linnakangas (#2)
Re: gistVacuumUpdate

On Wed, Jan 18, 2012 at 10:05 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

On 13.01.2012 06:24, YAMAMOTO Takashi wrote:

hi,

gistVacuumUpdate was removed when old-style VACUUM FULL was removed.
i wonder why.
it was not practical and REINDEX is preferred?

anyway, the removal seems incomplete and there are some leftovers:
       F_TUPLES_DELETED
       F_DELETED
       XLOG_GIST_PAGE_DELETE

Hmm, in theory we might bring back support for deleting pages in the future,
I'm guessing F_DELETED and the WAL record type were left in place because of
that.

I guess it was an oversight, because GistPageSetDeleted() is being
used in gistRedoPageDeleteRecord() and GistPageIsDeleted() in a few
other places

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación