At Wed, 18 Dec 2019 12:30:51 -0500, Robert Haas <robertmh...@gmail.com> wrote in > On Wed, Dec 18, 2019 at 12:06 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > It seems like it'd be worth subdividing "<anonymous>" into the actual > > anonymous allocations and the allocator overhead (which is both > > padding and whatever the shmem allocator itself eats). Maybe call > > the latter "<overhead>". After which, I'd be tempted to call the > > free space "<free>" rather than giving it a null name. > > Here's a new version that takes a slightly different approach: it adds > an additional column to the view for "allocated_size," so that you can > see both what was requested and what you actually got. With this
The doc is saying that "size" is "Size of the allocation" and "allocated_size" is "size including padding". It seems somewhat confusing to me. I'm not sure what wording is best but I think people use net/gross wordings to describe like that. > approach, you can do interesting things like: > > select *, off - lag(off + allocated_size, 1) over () as hole_size from > (select * from pg_shmem_allocations order by 2) x; > > ...which didn't work very well with the previous version. > All of this makes me think that we might want to do some followup to > (1) convert anonymous allocations to non-anonymous allocations, for > inspectability, and (2) do some renaming to get better stylistic > agreement between the names of various shared memory chunks. But I > think that work is properly done after this patch is committed, not > before. I agree to (2), but regarding (1), most or perhaps all of the anonymous allocations seems belonging to one of the shared hashes but are recognized as holes shown by the above statement. So the current output of the view is wrong in that sense. I think (1) should be resolved before adding the view. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
