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: