On Thu, Jan 31, 2019 at 2:02 PM John Naylor <john.nay...@2ndquadrant.com> wrote: > > On Thu, Jan 31, 2019 at 6:37 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Jan 30, 2019 at 8:11 PM John Naylor <john.nay...@2ndquadrant.com> > > wrote: > > > > > > 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. > > FYI, the second comment is still present in v20. >
oops, forgot to include in commit after making a change, done now. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
v21-0001-Avoid-creation-of-the-free-space-map-for-small-heap-.patch
Description: Binary data
