On Tue, Mar 20, 2018 at 5:01 AM, Tom Lane wrote:
> Alexander Kuzmenkov writes:
>> The updated version looks good to me.
>
> LGTM too. Pushed with some trivial cosmetic adjustments.
>
> regards, tom lane
Thank you both!
Best regards,
Anton
Alexander Kuzmenkov writes:
> The updated version looks good to me.
LGTM too. Pushed with some trivial cosmetic adjustments.
regards, tom lane
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
The updated version looks good to me. make installcheck under valgrind fi
Hi,
attached is the patch that uses two memory contexts.
One for calling the inner consistent function,
and a new one for keeping the traversal memory of the inner consistent function.
I run some test to compare the memory footprints. I report the total maximum
memory usage (sum of all children)
>> The better alternative may be to have two temporary memory contexts,
>> one per-tuple for calling the inner consistent method and one
>> per-index-scan for the traversal memory.
>
>
> Yes, this seems to be a better way of fixing the problem without introducing
> regressions mentioned by Tom. We'
On 04.03.2018 20:20, Anton Dignös wrote:
The better alternative may be to have two temporary memory contexts,
one per-tuple for calling the inner consistent method and one
per-index-scan for the traversal memory.
Yes, this seems to be a better way of fixing the problem without
introducing regr
=?UTF-8?Q?Anton_Dign=C3=B6s?= writes:
>> Looking at the patch, I see that you changed the lifetime of the temporary
>> context from per-tuple to per-index-scan. It is not obvious that this change
>> is correct.
> The problem before this patch was that the traversalMemoryContext in
> this function
Hi Alexander,
thanks for the feedback.
> I can reproduce the high memory consumption with your queries.
>
> Looking at the patch, I see that you changed the lifetime of the temporary
> context from per-tuple to per-index-scan. It is not obvious that this change
> is correct. Could you explain, wh
Hi Anton,
I can reproduce the high memory consumption with your queries.
Looking at the patch, I see that you changed the lifetime of the
temporary context from per-tuple to per-index-scan. It is not obvious
that this change is correct. Could you explain, what memory context are
involved in t
Hi,
I came across a strange memory problem when doing an IndexJoin using
spgist on boxes.
I also found it mentioned here:
https://www.postgresql.org/message-id/flat/CAPqRbE5vTGWCGrOc91Bmu-0o7CwsU0UCnAshOtpDR8cSpSjy0g%40mail.gmail.com#capqrbe5vtgwcgroc91bmu-0o7cwsu0ucnashotpdr8cspsj...@mail.gmail.c
10 matches
Mail list logo
