On Wed, Dec 18, 2019 at 9:53 PM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > 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.
I don't think I'd find that particularly clear. It seems to me that if the second size includes padding, then the first one differs in not including padding, so I'm not really sure where the confusion is. I thought about writing, for the first one, that is the requested size of the allocation, but that seemed like it might confuse someone by suggesting that the actual size of the allocation might be less than what was requested. I also thought about describing the first one as the size excluding padding, but that seems redundant. Maybe it would be good to change the second one to say "Size of the allocation including padding added by the allocator itself." > > 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. I guess I don't understand how this makes the output wrong. Either the allocations have a name, or they are anonymous. This dumps everything that has a name. What would you suggest? It seems to me that it's more appropriate for this patch to just tell us about what's in shared memory, not change what's in shared memory. If we want to do the latter, that's a job for another patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
