| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Reducing relcache memory usage: deduping index shapes |
| Date: | 2026-09-02 08:09:54 |
| Message-ID: | f84abf0b-0e50-430a-b85d-862a51209780@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Can you provide information about how much memory is being saved from 0004+0005?
>
> Attached the output for a query on catcache/relcache memory context
> data, with output of master and the full patchset.
>
> From Master to 0003, we go from 287872 bytes total to 141312 bytes
> total spent on "index info" contexts (some of which moved into other
> contexts, some new, but a net saving of 130kB). 0004+0005 bring that
> down all the way to 45392 bytes; most of which is just avoiding the
> large overhead of the pre-allocated Blocks of memory, saving another
> 95kB.
Did you just startup the server and run that query or did you run some
something first to populate the relcache?
Maybe I'm missing something but in my understanding the relcache is
populated as relations are accessed.
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2026-09-02 08:19:29 | Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator |
| Previous Message | Dean Rasheed | 2026-09-02 08:08:41 | Re: Global temporary tables |