Dept of ugly hacks: eliminating padding space in systemindexes
in [PgSql]
|
From: Andrew Dunstan on 23 Jun 2008 17:49 Tom Lane wrote: > Cutting a third off the size of a system index has got to be worth > something, but is it worth a hack as ugly as this one? > > I think so. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mark Mielke on 23 Jun 2008 18:41 Andrew Dunstan wrote: > Tom Lane wrote: >> Cutting a third off the size of a system index has got to be worth >> something, but is it worth a hack as ugly as this one? >> > > I think so. Were you able to time any speedup? Is this something that would benefit installations with a lot of metadata? I presume most of this information normally easily fits in cache most of the time? I am trying to understand what exactly it is worth... :-) Cheers, mark -- Mark Mielke <mark(a)mielke.cc> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Teodor Sigaev on 24 Jun 2008 02:12 > dead easy to implement this: effectively, we just decree that the > index column storage type for NAME is always CSTRING. Because the Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as it's done for GiST and GIN indexes. -- Teodor Sigaev E-mail: teodor(a)sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Shane Ambler on 24 Jun 2008 02:40 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 24 Jun 2008 11:02
Shane Ambler wrote: > 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. There are PostgreSQL users out there with more than 100,000 tables per server instance. This will make more of a difference to them. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |