Small reduction in memory usage of index relcache entries

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Small reduction in memory usage of index relcache entries
Date: 2013-04-12 19:49:51
Message-ID: 5168655F.9080308@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
remove-fields-from-relationaminfo.patch text/x-diff 2.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-04-12 20:03:48 Re: Enabling Checksums
Previous Message Andres Freund 2013-04-12 19:34:17 Re: Enabling Checksums