Re: Dept of ugly hacks: eliminating padding space in system indexes

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

In response to

Responses

Browse pgsql-hackers by date

  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