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
