Re: Backend memory dump analysis
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>,
Vladimir Sitnikov <sitnikov.vladimir@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-03-27T23:55:49Z
Lists: pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > How about this one as well: > portal->portalContext = AllocSetContextCreate(TopPortalContext, > "PortalContext", > ALLOCSET_SMALL_SIZES); > + MemoryContextCopySetIdentifier(portal->portalContext, name); Seems reasonable, although I think if you were to delay setting the name till the end of that function, you could point to portal->name and avoid the extra pstrdup. Maybe that's useless microoptimization. > The term CopySetIdentifier has confused me a bit. (What's a "set > identifier"?) Maybe use CopyAndSetIdentifier? (We similarly have > MemoryContextResetAndDeleteChildren.) No objection, do you want to make the change? > I'm also not clear why this doesn't undo the previous optimization that > preferred making the identifier a compile time-constant. Aren't we now > just going back to doing a pstrdup() every time? Huh? It's not undoing that, it's doubling down on it; the "name" now *has* to be a compile-time constant. Only for contexts that seem worthy of carrying extra ID information, which is a small minority, do we bother setting the ident field. Even for those, in the majority of cases we can avoid an extra strcpy because the identity info is being carried somewhere inside the context already. regards, tom lane
Commits
-
Add memory context identifier to portal context
- 94c1f9ba11d1 11.0 landed
-
Rename MemoryContextCopySetIdentifier() for clarity
- bbca77623fb5 11.0 landed
-
Allow memory contexts to have both fixed and variable ident strings.
- 442accc3fe0c 11.0 landed
-
Rethink MemoryContext creation to improve performance.
- 9fa6f00b1308 11.0 cited