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 probably need
>>> to also set
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 probably need
>>> to also set
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 them.
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 ch
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
> avoid O(N^2) perf
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
> potential for more
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 that we've not seen
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 problem reported in the
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 [DBNAME]
NUM_STMTS de
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. The code block ex
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
11 matches
Mail list logo