Re: WIP: Avoid creation of the free space map for small tables

On Mon, Dec 3, 2018 at 9:46 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Nov 29, 2018 at 3:07 PM John Naylor <jcnaylor(at)gmail(dot)com> wrote:
> >
>
v8 code:
+fsm_local_set(Relation rel, BlockNumber new_nblocks)
+{
+ BlockNumber blkno,
+ cached_target_block;
+
+ /*
+ * Mark blocks available starting after the last block number we have
+ * cached, and ending at the current last block in the relation.
+ * When we first set the map, this will flag all blocks as available
+ * to try. If we reset the map while waiting for a relation
+ * extension lock, this will only flag new blocks as available,
+ * if any were created by another backend.
+ */
+ for (blkno = fsm_local_map.nblocks; blkno < new_nblocks; blkno++)
+ fsm_local_map.map[blkno] = FSM_LOCAL_AVAIL;

v9 code:
+static void
+fsm_local_set(Relation rel, BlockNumber nblocks)
+{
+ BlockNumber blkno,
+ cached_target_block;
+
+ for (blkno = 0; blkno < nblocks; blkno++)
+ fsm_local_map.map[blkno] = FSM_LOCAL_AVAIL;

What is the reason for the above code change in the latest patch version?

It would be good if you add few comments atop functions
GetPageWithFreeSpace, RecordAndGetPageWithFreeSpace and
RecordPageWithFreeSpace about their interaction with local map.

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