From: | Shane Ambler <pgsql(at)Sheeky(dot)Biz> |
---|---|
To: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Dept of ugly hacks: eliminating padding space in system indexes |
Date: | 2008-06-24 06:40:09 |
Message-ID: | 486096C9.1070909@Sheeky.Biz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-06-24 07:07:50 | Re: pg_stat_statements |
Previous Message | Yoshiyuki Asaba | 2008-06-24 06:26:36 | Re: Git Repository for WITH RECURSIVE and others |