Re: Unhappy about API changes in the no-fsm-for-small-rels patch

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: John Naylor <john.naylor@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-05T13:25:30Z
Lists: pgsql-hackers
On Sat, May 4, 2019 at 2:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, May 3, 2019 at 2:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, May 3, 2019 at 11:43 AM John Naylor <john.naylor@2ndquadrant.com> wrote:
>
> Attached is a revert patch.  John, can you please once double-check to
> ensure I have not missed anything?
>
> To summarize for everyone:  This patch avoids the fsm creation for
> small relations (which is a small but good improvement as it saves
> space).   This patch was using a process local map to track the first
> few blocks and was reset as soon as we get the block with enough free
> space.   It was discussed in this thread that it would be better to
> track the local map in relcache and then invalidate it whenever vacuum
> frees up space in the page or when FSM is created.   There is a
> prototype patch written for the same, but it is not 100% clear to me
> that the new idea would be a win in all cases (like code complexity or
> API design-wise) especially because resetting the map is not
> straight-forward.  As time was not enough, we couldn't complete the
> patch from all aspects to see if it is really better in all cases.
>
> We have two options (a) revert this patch and try the new approach in
> next release, (b) keep the current patch and replace with the new
> approach if it turns out to be better in next release.
>
> So, do we want to keep this feature for this release?
>
> I am fine going with option (a), that's why I have prepared a revert
> patch, but I have a slight fear that the other option might not turn
> out to be better and even if it is then we can anyway replace it as
> shown in the prototype, so going with option (b) doesn't sound to be
> dumb.
>
> Anybody else wants to weigh in?
>

I understand that we have to take a call here shortly, but as there is
a weekend so I would like to wait for another day to see if anyone
else wants to share his opinion.

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



Commits

  1. Revert "Avoid the creation of the free space map for small heap relations".

  2. Improve code comments in b0eaa4c51b.

  3. During pg_upgrade, conditionally skip transfer of FSMs.

  4. Add more tests for FSM.

  5. Fix typos in commit 8586bf7ed8.

  6. tableam: introduce table AM infrastructure.

  7. Clear the local map when not used.

  8. Doc: Update the documentation for FSM behavior for small tables.

  9. Make FSM test portable.

  10. Avoid creation of the free space map for small heap relations, take 2.