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
-
Revert "Avoid the creation of the free space map for small heap relations".
- 7db0cde6b58e 12.0 landed
-
Improve code comments in b0eaa4c51b.
- 06c8a5090ed9 12.0 cited
-
During pg_upgrade, conditionally skip transfer of FSMs.
- 13e8643bfc29 12.0 cited
-
Add more tests for FSM.
- 6f918159a97a 12.0 cited
-
Fix typos in commit 8586bf7ed8.
- a6e48da08844 12.0 cited
-
tableam: introduce table AM infrastructure.
- 8586bf7ed888 12.0 cited
-
Clear the local map when not used.
- 9c32e4c35026 12.0 cited
-
Doc: Update the documentation for FSM behavior for small tables.
- 29d108cdecbe 12.0 cited
-
Make FSM test portable.
- 08ecdfe7e5e0 12.0 cited
-
Avoid creation of the free space map for small heap relations, take 2.
- b0eaa4c51bbf 12.0 cited