On Wed, May 7, 2014 at 5:54 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-05-07 17:48:15 -0400, Robert Haas wrote: >> On Tue, May 6, 2014 at 6:09 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> >> I guess I'd vote for >> >> ditching the allocated column completely and outputting the memory >> >> allocated without ShmemIndex using some fixed tag (like "ShmemIndex" >> >> or "Bootstrap" or "Overhead" or something). >> > >> > My way feels slightly cleaner, but I'd be ok with that as well. There's >> > no possible conflicts with an actual segment... In your variant the >> > unallocated/slop memory would continue to have a NULL key? >> >> Yeah, that seems all right. > > Hm. Not sure what you're ACKing here ;).
The idea of giving the unallocated memory a NULL key. >> One way to avoid conflict with an actual segment would be to add an >> after-the-fact entry into ShmemIndex representing the amount of memory >> that was used to bootstrap it. > > There's lots of allocations from shmem that cannot be associated with > any index entry though. Not just ShmemIndex's own entry. Most > prominently most of the memory used for SharedBufHash isn't actually > associated with the "Shared Buffer Lookup Table" entry - imo a > dynahash.c defficiency. Hmm, I don't know what to do about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
