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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Date: 2018-03-26 13:58:21
Message-ID: CAA4eK1Lyi12WcWp-xzyBuh2U3x3jw5WkBH5Om0x=OhW+2cfGPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 25, 2018 at 12:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Claudio Freire <klaussfreire(at)gmail(dot)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?
>

Yeah, sounds like a better idea and I think we already do something
similar during relation extension (when we add blocks in bulk) via
UpdateFreeSpaceMap. Is that what you have in mind? It seems like
Claudio's method is somewhat more selective when deciding which
branches to traverse, but it appears complicated as compared to what
you are proposing.

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.
>

+1.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2018-03-26 14:00:36 Re: WIP: a way forward on bootstrap data
Previous Message Pavel Stehule 2018-03-26 13:45:01 Re: Re: csv format for psql