Short-living Memory Context in the optimiser
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50815psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 10:37 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50815_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50815_3 && git checkout t50815_3Patchset v3 (message #3) is on t50815_3
Hi,
Here is a rebased and slightly commented Tom's patch separated from the
discussion [1]/messages/by-id/1367418.1708816059@sss.pgh.pa.us.
I still occasionally see that planner peak memory consumption is
triggered by selectivity estimation of massive arrays and clauses
generated for multiple partitions.
I think that in case of a growing number of selectivity estimations, the
planner should consume memory in some scalable manner, so this thread is
an attempt to draw community attention to this issue.
I question some decisions in that patch. For example, field 'depth' and
even 'usage' can be incorporated inside the MemoryContext structure.
This can make the reset function safer. To avoid overhead, it may be
used only for the 'short-living' class of memory contexts, which can be
declared with an additional parameter of AllocSetContextCreate on a
context creation.
[1]: /messages/by-id/1367418.1708816059@sss.pgh.pa.us
--
regards, Andrei Lepikhov
On Wed, Dec 25, 2024 at 11:56:24AM +0700, Andrei Lepikhov wrote:
Here is a rebased and slightly commented Tom's patch separated from the
discussion [1].
Seems to me that there is no patch?
--
Michael
On 12/25/24 12:30, Michael Paquier wrote:
On Wed, Dec 25, 2024 at 11:56:24AM +0700, Andrei Lepikhov wrote:
Here is a rebased and slightly commented Tom's patch separated from the
discussion [1].Seems to me that there is no patch?
--
Michael
Pardon me, patch attached.
--
regards, Andrei Lepikhov