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

On Wed, Jan 16, 2019 at 10:10 PM John Naylor
<john(dot)naylor(at)2ndquadrant(dot)com> wrote:
>
> On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Jan 11, 2019 at 3:54 AM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
> > 1.
> > Commit message:
> > > Any pages with wasted free space become visible at next relation extension, so we still control table bloat.
> >
> > I think the free space will be available after the next pass of
> > vacuum, no? How can relation extension make it available?
>
> To explain, this diagram shows the map as it looks for different small
> table sizes:
>
> 0123
> A
> NA
> ANA
> NANA
>
> So for a 3-block table, the alternating strategy never checks block 1.
> Any free space block 1 has acquired via delete-and-vacuum will become
> visible if it extends to 4 blocks. We are accepting a small amount of
> bloat for improved performance, as discussed. Would it help to include
> this diagram in the README?
>

Yes, I think it would be good if you can explain the concept of
local-map with the help of this example.

> > 2.
> > +2. For very small heap relations, the FSM would be relatively large and
> > +wasteful, so as of PostgreSQL 12 we refrain from creating the FSM for
> > +heaps with HEAP_FSM_CREATION_THRESHOLD pages or fewer, both to save space
> > +and to improve performance. To locate free space in this case, we simply
> > +iterate over the heap, trying alternating pages in turn. There may be some
> > +wasted free space in this case, but it becomes visible again upon next
> > +relation extension.
> >
> > a. Again, how space becomes available at next relation extension.
> > b. I think there is no use of mentioning the version number in the
> > above comment, this code will be present from PG-12, so one can find
> > out from which version this optimization is added.
>
> It fits with the reference to PG 8.4 earlier in the document. I chose
> to be consistent, but to be honest, I'm not much in favor of a lot of
> version references in code/READMEs.
>

Then let's not add a reference to the version number in this case. I
also don't see much advantage of adding version number at least in
this case.

>
> I'll include these with some grammar corrections in the next version.
>

Okay, thanks!

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