On 12/11/2017 05:27 PM, Tom Lane wrote: > I wrote: >> While fooling around with a different problem, I got annoyed at how slow >> MemoryContext creation and deletion is. > > Looking at this some more, there's another micro-optimization we could > make, which is to try to get rid of the strlen+strcpy operations needed > for the context name. (And yes, I'm seeing those show up in profiles, > to the tune of a couple percent of total runtime in some examples.) > > For a *very* large majority of the callers of AllocSetContextCreate, > the context name is a simple C string constant, so we could just store > the pointer to it and save the space and cycles required to copy it. > This would require providing a separate API for the few callers that are > actually passing transient strings, but that's easy enough. I envision > AllocSetContextCreate becoming a wrapper macro for > "AllocSetContextCreateExtended", which'd take a flag argument specifying > whether the context name needs to be copied. > > However, unless we want to run around and touch all the ~ 150 calls > with constant arguments, we'd have to set things up so that the default > behavior for AllocSetContextCreate is to not copy. This risks breaking > callers in extensions. Not entirely sure if it's worth that --- any > thoughts? >
I don't think silently breaking extensions is particularly attractive option, so I guess we'll have to run around and tweak the ~150 calls. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
