Re: Analysis on backend-private memory usage (and a patch) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Analysis on backend-private memory usage (and a patch)
Date
Msg-id CAM-w4HMnzgtYwH2ADDWsf338WO2-Bh=eZeha9ZCCck0Ap5wiJA@mail.gmail.com
Whole thread Raw
In response to Analysis on backend-private memory usage (and a patch)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
<p dir="ltr"><br /> On 4 Sep 2013 20:46, "Heikki Linnakangas" <<a
href="mailto:hlinnakangas@vmware.com">hlinnakangas@vmware.com</a>>wrote:<br /> ><p dir="ltr">> One fairly
simplething we could do is to teach catcache.c to resize the caches. Then we could make the initial size of all the
syscachesmuch smaller. At the moment, we use fairly caches for catalogs like pg_enum (256 entries) and pg_usermapping
(128),even though most databases don't use those features at all. If they could be resized on demand, we could easily
allocatethem initially with just, say, 4 entries.<p dir="ltr">If most databases don't use the feature at all, tsparser,
enums,etc, why not start out with *no* cache and only build one when it's first needed? This would also mean there's
lessoverhead for implementing new features that aren't universally used. 

pgsql-hackers by date:

Previous
From: Florian Weimer
Date:
Subject: Re: get rid of SQL_ASCII?
Next
From: Hannu Krosing
Date:
Subject: Re: [PERFORM] encouraging index-only scans