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 |
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 |