Обсуждение: gistVacuumUpdate
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_DELETEDF_DELETEDXLOG_GIST_PAGE_DELETE YAMAMOTO Takashi
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
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 > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com
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
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