On Mon, Jul 18, 2016 at 10:05 AM, Tom Lane wrote:
> Jan Wieck writes:
> > In the meantime, would it be appropriate to backpatch the double linking
> > of memory context children at this time? I believe it has had plenty of
> > testing in the 9.6 cycle to be sure it didn't break anything.
>
> I'm
Merlin Moncure writes:
> Hm, maybe, instead of trying to figure out if in a loop, set a
> 'called' flag with each statement and only cache when touched the
> second time. (If that's easier, dunno).
Well, then you just guarantee to lose once. I think Jan's sketch of
marking potentially-cacheabl
Jan Wieck writes:
> In the meantime, would it be appropriate to backpatch the double linking
> of memory context children at this time? I believe it has had plenty of
> testing in the 9.6 cycle to be sure it didn't break anything.
I'm concerned about the ABI breakage risk from changing a data str
On Mon, Jul 18, 2016 at 8:59 AM, Jan Wieck wrote:
>
>
> On Mon, Jul 18, 2016 at 9:43 AM, Tom Lane wrote:
>>
>> Merlin Moncure writes:
>> > BTW, while the fix does address the cleanup performance issue, it's
>> > still the case that anonymous code blocks burn up lots of resident
>> > memory (my 3
On Mon, Jul 18, 2016 at 9:43 AM, Tom Lane wrote:
> Merlin Moncure writes:
> > BTW, while the fix does address the cleanup performance issue, it's
> > still the case that anonymous code blocks burn up lots of resident
> > memory (my 315k example I tested with ate around 8gb IIRC) when run
> > lik
Merlin Moncure writes:
> BTW, while the fix does address the cleanup performance issue, it's
> still the case that anonymous code blocks burn up lots of resident
> memory (my 315k example I tested with ate around 8gb IIRC) when run
> like this. My question is, if the pl/pgsql code block is anonym
On Sat, Jul 16, 2016 at 2:47 PM, Jan Wieck wrote:
> On Tue, Jul 12, 2016 at 3:29 PM, Merlin Moncure wrote:
>>
>> I've noticed that pl/pgsql functions/do commands do not behave well
>> when the statement resolves and frees memory. To be clear:
>>
>> FOR i in 1..100
>> LOOP
>> INSERT INTO f
BTW, here is the email thread about double-linking MemoryContext children
patch, that Kevin at the end committed to master.
https://www.postgresql.org/message-id/55F2D834.8040106%40wi3ck.info
Regards, Jan
On Sat, Jul 16, 2016 at 3:47 PM, Jan Wieck wrote:
>
>
> On Tue, Jul 12, 2016 at 3:29 PM
On Tue, Jul 12, 2016 at 3:29 PM, Merlin Moncure wrote:
> I've noticed that pl/pgsql functions/do commands do not behave well
> when the statement resolves and frees memory. To be clear:
>
> FOR i in 1..100
> LOOP
> INSERT INTO foo VALUES (i);
> END LOOP;
>
> ...runs just fine while
>
> BE
I've noticed that pl/pgsql functions/do commands do not behave well
when the statement resolves and frees memory. To be clear:
FOR i in 1..100
LOOP
INSERT INTO foo VALUES (i);
END LOOP;
...runs just fine while
BEGIN
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
...
INSE
10 matches
Mail list logo
