Re: Trim the heap free memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: shawn wang <shawn(dot)wang(dot)pg(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trim the heap free memory
Date: 2024-09-15 18:22:14
Message-ID: 953078.1726424534@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

shawn wang <shawn(dot)wang(dot)pg(at)gmail(dot)com> writes:
> I have successfully registered my patch for the commitfest. However, upon
> integration, I encountered several errors during the testing phase. I am
> currently investigating the root causes of these issues and will work on
> providing the necessary fixes.

I should think the root cause is pretty obvious: malloc_trim() is
a glibc-ism.

I'm fairly doubtful that this is something we should spend time on.
It can never work on any non-glibc platform. Even granting that
a Linux-only feature could be worth having, I'm really doubtful
that our memory allocation patterns are such that malloc_trim()
could be expected to free a useful amount of memory mid-query.
The single test case you showed suggested that maybe we could
usefully prod glibc to free memory at query completion, but we
don't need all this interrupt infrastructure to do that. I think
we could likely get 95% of the benefit with about a five-line
patch.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-09-15 18:31:13 Re: how to speed up 002_pg_upgrade.pl and 025_stream_regress.pl under valgrind
Previous Message Tomas Vondra 2024-09-15 18:20:01 how to speed up 002_pg_upgrade.pl and 025_stream_regress.pl under valgrind