Re: [HACKERS] Double linking MemoryContext children

2015-12-08 Thread Kevin Grittner
On Sun, Dec 6, 2015 at 7:30 PM, Jim Nasby wrote: > On 9/14/15 7:24 AM, Jan Wieck wrote: >> On 09/12/2015 11:35 AM, Kevin Grittner wrote: >> >>> On the other hand, a grep indicates that there are two places that >>> MemoryContextData.nextchild is set (and we therefore

Re: [HACKERS] Double linking MemoryContext children

2015-12-08 Thread Thom Brown
On 7 December 2015 at 01:30, Jim Nasby wrote: > On 9/14/15 7:24 AM, Jan Wieck wrote: >> >> On 09/12/2015 11:35 AM, Kevin Grittner wrote: >> >>> On the other hand, a grep indicates that there are two places that >>> MemoryContextData.nextchild is set (and we therefore

Re: [HACKERS] Double linking MemoryContext children

2015-12-06 Thread Jim Nasby
On 9/14/15 7:24 AM, Jan Wieck wrote: On 09/12/2015 11:35 AM, Kevin Grittner wrote: On the other hand, a grep indicates that there are two places that MemoryContextData.nextchild is set (and we therefore probably need to also set the new field), and Jan's proposed patch only changes one of

Re: [HACKERS] Double linking MemoryContext children

2015-09-14 Thread Jan Wieck
On 09/12/2015 11:35 AM, Kevin Grittner wrote: On the other hand, a grep indicates that there are two places that MemoryContextData.nextchild is set (and we therefore probably need to also set the new field), and Jan's proposed patch only changes one of them. If we do this, I think we need to

Re: [HACKERS] Double linking MemoryContext children

2015-09-12 Thread Kevin Grittner
Jan Wieck wrote: >>> On 09/11/2015 09:38 AM, Tom Lane wrote: Seems less invasive to fix SPI to delete in the opposite order? > The remaining numbers indicate that other contexts are mostly used in > the intended fashion, but not strictly. This means there is definitely >

Re: [HACKERS] Double linking MemoryContext children

2015-09-12 Thread Tom Lane
Kevin Grittner writes: > I guess the question is whether to add a pointer for each memory > context to give the MemoryContextSetParent() function O(1) > performance characteristics or add comments in front of this > function to document how callers should organize their code to

Re: [HACKERS] Double linking MemoryContext children

2015-09-11 Thread Tom Lane
Jan Wieck writes: > The attached script demonstrates an O(N^2) problem we recently became > aware of. The script simply executes a large anonymous code block that > doesn't do anything useful. Usage is > ./t1.py [NUM_STMTS] | psql [DBNAME] > NUM_STMTS defaults to 20,000.

[HACKERS] Double linking MemoryContext children

2015-09-11 Thread Jan Wieck
The attached script demonstrates an O(N^2) problem we recently became aware of. The script simply executes a large anonymous code block that doesn't do anything useful. Usage is ./t1.py [NUM_STMTS] | psql [DBNAME] NUM_STMTS defaults to 20,000. The code block executes rather fast, but the

Re: [HACKERS] Double linking MemoryContext children

2015-09-11 Thread Jan Wieck
On 09/11/2015 09:38 AM, Tom Lane wrote: Jan Wieck writes: The attached script demonstrates an O(N^2) problem we recently became aware of. The script simply executes a large anonymous code block that doesn't do anything useful. Usage is ./t1.py [NUM_STMTS] | psql

Re: [HACKERS] Double linking MemoryContext children

2015-09-11 Thread Tom Lane
Jan Wieck writes: > On 09/11/2015 09:38 AM, Tom Lane wrote: >> Seems less invasive to fix SPI to delete in the opposite order? > That would assume that there are no other code paths that destroy memory > contexts out of LIFO order. Given that we've not seen this sort of

Re: [HACKERS] Double linking MemoryContext children

2015-09-11 Thread Jan Wieck
On 09/11/2015 09:58 AM, Tom Lane wrote: Jan Wieck writes: On 09/11/2015 09:38 AM, Tom Lane wrote: Seems less invasive to fix SPI to delete in the opposite order? That would assume that there are no other code paths that destroy memory contexts out of LIFO order. Given