Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Amit Kapila <amit.kapila16@gmail.com>, John Naylor <john.naylor@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-06T16:16:44Z
Lists: pgsql-hackers 
On Mon, May 6, 2019 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > ... I guess you could incur the overhead repeatedly if the relation starts
> > out at 1 block, grows to 4, is vacuumed back down to 1, lather, rinse,
> > repeat, but is that actually realistic?
>
> While I've not studied the patch, I assumed that once a relation has an
> FSM it won't disappear.  Making it go away again if the relation gets
> shorter seems both fairly useless and a promising source of bugs.

Right, I think so too.  That's not what I as going for, though.  I was
trying to discuss a scenario where the relation repeatedly grows,
never reaching the size at which the FSM would be created, and then is
repeatedly truncated again.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.