From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Thinking about inventing MemoryContextSetParent |
Date: | 2011-09-12 22:48:13 |
Message-ID: | 17244.1315867693@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of sb sep 10 19:03:23 -0300 2011:
>> I'm considering inventing a new mcxt.c primitive,
>>
>> void MemoryContextSetParent(MemoryContext context, MemoryContext new_parent);
>>
>> which would have the effect of delinking "context" from its current
>> parent context and attaching it as a child of the new specified parent.
>> (Any child contexts that it has would naturally follow along.)
>> Because of the way that mcxt.c handles parent/child links, there is no
>> palloc required and so the operation cannot fail.
> Interesting. I wonder whether we could use this somehow to fix
> performance problems in certain subtransaction code paths that "reassign
> stuff to the parent"; instead of moving pointers or memory around,
> perhaps we could do something like this. Not that I have actually
> looked into it.
Yeah, I think it would be worth looking for places where we are either
copying lots-o-stuff or else jumping through weird hoops to avoid doing
that. I'm about halfway through rewriting the plancache and SPIPlan
stuff using this mechanism, and it seems to be coming out a whole lot
nicer --- it'll probably end up with less parse-tree-copying overall,
and much less risk of leaking memory when you hit an error partway
through constructing a cached plan. (The existing SPI code gets a
completely failing grade on that aspect :-(.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-12 23:12:59 | Re: [WIP] Caching constant stable expressions per execution |
Previous Message | Dermot | 2011-09-12 21:33:16 | Sponsored development |