Re: Subquery pull-up increases jointree search space

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Subquery pull-up increases jointree search space
Date: 2026-06-13 19:56:10
Message-ID: 5b8938a5-de0c-40d4-a340-46664dcb8926@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13/06/2026 15:54, Tomas Vondra wrote:
> Anyway, it seems very convenient to use, and gives me data roughly in
> line with the manual tracing. It produces much nicer / more complete
> reports, and it's way faster (a minute vs. an hour).

From my side, I've spent some time working with heaptrack.
VALGRIND's macros work well for counting memory context allocations. However,
they do not cover memory context resets. Each type of memory reset - aset,
generation, and bump - needs its own custom routine. For bump.c, we also need to
use memory-checking tools to ensure memory chunks are handled correctly during
reset.

Another issue is that heaptrack turns off custom mem alloc and free reports in
each forked process. Because of this, I found no other way to re-enable it in a
specific backend than to write a trivial extension.

There are some positive possibilities if heaptrack is updated. If it will add
the 'tagged' memory allocations feature, we could get a clear allocation profile
for each context, including system malloc and free calls.

Overall, this tool looks promising. It is lightweight, precise, provides
detailed information, and is widely used by support teams on Linux and Windows.
However, it needs some changes before postgres can use it. For now, it is not a
viable option.

--
regards, Andrei Lepikhov,
pgEdge

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ed Behn 2026-06-13 20:19:28 Re: access numeric data in module
Previous Message Nikita Malakhov 2026-06-13 19:43:17 Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table