Re: Memory consumed by paths during partitionwise join planning

From: Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory consumed by paths during partitionwise join planning
Date: 2025-06-27 10:01:04
Message-ID: 695ac356-87e6-45b3-a487-1e07b526ed52@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/2/2024 13:51, Ashutosh Bapat wrote:
> On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> First patch is no longer required. Here's rebased set
>
> The patches are raw. make check has some crashes that I need to fix. I
> am waiting to hear whether this is useful and whether the design is on
> the right track.
I think this project is quite important to move forward and discover how
far we can go this way. In the attachment, the rebased patch set with
fixes allows it to pass the regression tests.

This idea of a refcounter resolves the problem with blind usage of
add_path. It is not only about extensions, which sometimes want to add
paths on different levels of the join tree and don't care about dangling
pointers. It is also about possible hidden bugs (a freed path staying in
the path list, just not employed) that aren't yet detected due to
costings and low test coverage.

--
regards,
Andrei Lepikhov
Postgres Professional

Attachment Content-Type Size
0001-Basic-infrastructure-to-link-unlink-and-free-pathnod-20250627.patch text/plain 9.5 KB
0002-Actual-code-to-use-pathnode-referencing-infrastructu-20250627.patch text/plain 22.3 KB
0003-Local-variables-pointing-to-path-node-used-repeatedl-20250627.patch text/plain 1.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shlok Kyal 2025-06-27 10:11:17 Re: Skipping schema changes in publication
Previous Message Andrey Borodin 2025-06-27 09:45:58 Re: Backpatching injection point core facilities to REL_17_STABLE