Re: Rethinking MemoryContext creation

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?

regards, tom lane