Mark Mielke wrote:
Not that I disagree with your change, but < 5 Mbytes in 4 Gbytes of RAM for my main PostgreSQL system that I manage seems like a drop in the bucket. Even if 40% of pg_class_relname and pg_proc_proname indices was saved - we're talking about 154 Kbytes saved on both those indices combined. Minor? Major? I bet I wouldn't notice unless my database requirements used up all RAM, and even then I'm suspecting it wouldn't matter except for border line cases (like all pages required for everything else happened to equal 4 Gbytes near exactly).
Guess the mileage will vary depending on the complexity of the db structure. Shorter names will also benefit more than longer ones.
The performance impact is probably going to be limited by our extensive use of catalog caches --- once a desired row is in a backend's catcache, it doesn't take a btree search to fetch it again. Still, the system indexes are probably "hot" enough to stay in shared buffers most of the time, and the smaller they are the more space will be left for other stuff, so I think there should be a distributed benefit.
My question is whether this is limited to system catalogs? or will this benefit char() index used on any table? The second would make it more worthwhile.
-- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
