Re: Rethinking MemoryContext creation

On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On 12/11/2017 05:27 PM, Tom Lane wrote:
>>> 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.
>
> Meh. I suppose that of the ~150 call sites, there are probably only
> a dozen or two where it would actually make a performance difference,
> so maybe this needn't be quite as invasive as I first thought.

I think changing only a subset of the call sites is unappealing
because, even though it may not make a measurable performance
difference in other cases, it may get cargo-culted into some place
where it does make a difference.

I also don't think silently breaking extensions is a terribly big deal
in this case. It seems likely that most extensions use static names
just as most of our internal stuff does. I'm going to guess that the
number of extensions that will actually break as a result of a change
in this area is probably very small - conceivably zero, and likely
less than five. I don't think we should be willing to uglify the core
code too much for that level of breakage.

But those are just my opinions. I am glad you are working on this; I
noticed this problem before and thought of trying to do something
about it, but ran out of time and ideas.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company