Re: Dept of ugly hacks: eliminating padding space in system indexes - Mailing list pgsql-hackers

From Mark Mielke
Subject Re: Dept of ugly hacks: eliminating padding space in system indexes
Date
Msg-id 48603DAF.6000501@mark.mielke.cc
Whole thread Raw
In response to Re: Dept of ugly hacks: eliminating padding space in system indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Dept of ugly hacks: eliminating padding space in system indexes  (Shane Ambler <pgsql@Sheeky.Biz>)
Re: Dept of ugly hacks: eliminating padding space in system indexes  ("Stephen R. van den Berg" <srb@cuci.nl>)
Re: Dept of ugly hacks: eliminating padding space in system indexes  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Tom Lane wrote: <blockquote cite="mid:4440.1214262551@sss.pgh.pa.us" type="cite"><blockquote type="cite"><pre
wrap="">Wereyou able to time any speedup?   </pre></blockquote><pre wrap="">
 
I didn't try; can you suggest any suitable benchmark?
 </pre></blockquote><br /> Unfortunately - no. I kind of think it won't benefit any of my databases in any noticeable
way.My numbers are similar to yours:<br /><br /><blockquote type="cite">pccyber=# select
pg_database_size('postgres');<br/>           4468332<br /><br /> pccyber=# select
pg_relation_size('pg_class_relname_nsp_index');<br/>             90112<br /><br /> pccyber=# select
pg_relation_size('pg_proc_proname_args_nsp_index');<br/>            294912<br /></blockquote><br /> Not that I disagree
withyour change, but < 5 Mbytes in 4 Gbytes of RAM for my main PostgreSQL system that I manage seems like a drop in
thebucket. Even if 40% of pg_class_relname and pg_proc_proname indices was saved - we're talking about 154 Kbytes saved
onboth those indices combined. Minor? Major? I bet I wouldn't notice unless my database requirements used up all RAM,
andeven then I'm suspecting it wouldn't matter except for border line cases (like all pages required for everything
elsehappened to equal 4 Gbytes near exactly).<br /><br /><blockquote cite="mid:4440.1214262551@sss.pgh.pa.us"
type="cite"><prewrap="">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. </pre></blockquote><br /> In my opinion it is 'do the right
thing',rather than a performance question. It seems to me that an index keeping tracking of space characters at the end
ofa name, char, varchar, or text does not make sense, and the right thing may be to do a more generic version of your
patch?In the few cases that space at the end matters, couldn't that be determined by re-checking the table row after
queryingit?<br /><br /> Cheers,<br /> mark<br /><br /><pre class="moz-signature" cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dept of ugly hacks: eliminating padding space in system indexes
Next
From: ITAGAKI Takahiro
Date:
Subject: Re: pg_stat_statements