Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Date
Msg-id 23846.1521919074@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
Claudio Freire <klaussfreire@gmail.com> writes:
> [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ]

I hadn't paid any attention to this patch previously, so maybe I'm
missing something ... but this sure seems like a very bizarre approach
to the problem.  If the idea is to fix the FSM's upper levels after
vacuuming a known sub-range of the table, why would you not proceed
by teaching FreeSpaceMapVacuum to recurse only within that sub-range
of page numbers?  This setup with a threshold seems entirely Rube
Goldbergian.  It's dependent on a magic threshold number that you can
only select by trial and error, and it's inevitably going to spend time
updating segments of the FSM tree that have nothing to do with the part
that's been vacuumed.

This approach would also offer a less arbitrary way to decide how often
to do the updates: choose a distance that has something to do with the
FSM's structure, so that we don't waste effort reconsidering fragments
of an upper tree page.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Damir Simunic
Date:
Subject: Proposal: http2 wire format
Next
From: Alexander Korotkov
Date:
Subject: Re: WIP: Covering + unique indexes.