Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

Claudio Freire <klaussfreire@gmail.com>

From: Claudio Freire <klaussfreire@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-02-27T15:06:04Z
Lists: pgsql-hackers

Attachments

On Mon, Feb 26, 2018 at 10:20 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> Thank you for updating patches!
>
> 0001 patch looks good to me except for the following unnecessary empty lines.
>
> +                * If there are no indexes then we should periodically
> vacuum the FSM
> +                * on huge relations to make free space visible early.
> +                */
> +               else if (nindexes == 0 && fsm_updated_pages >
> vacuum_fsm_every_pages)
> +               {
> +                       /* Vacuum the Free Space Map */
> +                       FreeSpaceMapVacuum(onerel, max_freespace);
> +                       fsm_updated_pages = 0;
> +                       max_freespace = 0;
> +               }
> +
> +
> +               /*
>
> @@ -913,10 +967,14 @@ lazy_scan_heap(Relation onerel, int options,
> LVRelStats *vacrelstats,
>
> vmbuffer, InvalidTransactionId,
>
> VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
>                                 END_CRIT_SECTION();
> +
>                         }
>
> 0002 patch looks good to me.
>
> For 0003 patch, I think fsm_set() function name could lead misreading
> because it actually not only sets the value but also returns the
> value. fsm_set_and_get() might be better?

Attached is the patchset modified as requested

Commits

  1. Do index FSM vacuuming sooner.

  2. Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() instead.

  3. While vacuuming a large table, update upper-level FSM data every so often.

  4. Simplify autovacuum work-item implementation