Small reduction in memory usage of index relcache entries
While debugging an out-of-memory situation, I noticed that the relcache
entry of each index consumes 2k of memory. From a memory dump:
...
pg_database_datname_index: 2048 total in 1 blocks; 712 free (0 chunks); 1336 used
pg_trigger_tgrelid_tgname_index: 2048 total in 1 blocks; 576 free (0 chunks); 1472 used
pg_rewrite_rel_rulename_index: 2048 total in 1 blocks; 576 free (0 chunks); 1472 used
pg_amproc_fam_proc_index: 2048 total in 1 blocks; 232 free (0 chunks); 1816 used
pg_opclass_oid_index: 2048 total in 1 blocks; 664 free (0 chunks); 1384 used
pg_index_indexrelid_index: 2048 total in 1 blocks; 664 free (0 chunks); 1384 used
pg_attribute_relid_attnum_index: 2048 total in 1 blocks; 528 free (0 chunks); 1520 used
pg_class_oid_index: 2048 total in 1 blocks; 664 free (0 chunks); 1384 used
Looking closer at where that memory is spent, a lot of it goes into the
FmgrInfo structs in RelationAmInfo. But some of them are outright unused
(ambuild, ambuildempty, amcostestimate, amoptions), and a few others
hardly are called so seldom that they hardly need to be cached
(ambuildelete, ambacuumcleanup). Removing those fields, patch attached,
reduces the memory usage nicely:
...
pg_database_datname_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_opclass_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_index_indexrelid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_class_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
This brings most index entries from two 1k blocks down to one 1k block.
A backend seems to load about 60 indexes into the cache for system
tables, so that saves about ~60 kB of memory for every backend at a minimum.
This isn't a huge difference, unless you access a huge number of
indexes. But the patch is trivial, and every little helps. Any
objections if I commit this to master?
- Heikki
Attachments:
remove-fields-from-relationaminfo.patchtext/x-diff; name=remove-fields-from-relationaminfo.patchDownload+18-14
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
Looking closer at where that memory is spent, a lot of it goes into the
FmgrInfo structs in RelationAmInfo. But some of them are outright unused
(ambuild, ambuildempty, amcostestimate, amoptions), and a few others
hardly are called so seldom that they hardly need to be cached
(ambuildelete, ambacuumcleanup). Removing those fields, patch attached,
reduces the memory usage nicely:
+1, but it would look nicer if you could encapsulate the code in some
macro analogous to GET_REL_PROCEDURE(), perhaps call it
GET_UNCACHED_REL_PROCEDURE()?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers