On Wed, Jan 30, 2019 at 8:11 PM John Naylor <john.nay...@2ndquadrant.com> wrote: > > On Wed, Jan 30, 2019 at 2:11 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > This is much better than the earlier version of test and there is no > > dependency on the vacuum. However, I feel still there is some > > dependency on how the rows will fit in a page and we have seen some > > related failures due to alignment stuff. By looking at the test, I > > can't envision any such problem, but how about if we just write some > > simple tests where we can check that the FSM won't be created for very > > small number of records say one or two and then when we increase the > > records FSM gets created, here if we want, we can even use vacuum to > > ensure FSM gets created. Once we are sure that the main patch passes > > all the buildfarm tests, we can extend the test to something advanced > > as you are proposing now. I think that will reduce the chances of > > failure, what do you think? > > That's probably a good idea to limit risk. I just very basic tests > now, and vacuum before every relation size check to make sure any FSM > extension (whether desired or not) is invoked. Also, in my last patch > I forgot to implement explicit checks of the block number instead of > assuming how many rows will fit on a page. I've used a plpgsql code > block to do this. >
-- Extend table with enough blocks to exceed the FSM threshold -- FSM is created and extended to 3 blocks The second comment line seems redundant to me, so I have removed that and integrated it in the main patch. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
v20-0001-Avoid-creation-of-the-free-space-map-for-small-heap-.patch
Description: Binary data