Dept of ugly hacks: eliminating padding space in system indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Dept of ugly hacks: eliminating padding space in system indexes
Date: 2008-06-23 19:52:36
Message-ID: 1770.1214250756@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I was thinking a bit about how we pad columns of type NAME to
fixed-width, even though they're semantically equivalent to C strings.
The reason for wasting that space is that it makes it possible to
overlay a C struct onto the leading columns of most system catalogs.
I don't wish to propose changing that (at least not today), but it
struck me that there is no reason to overlay a C struct onto index
entries, and that getting rid of the padding space would be even more
useful in an index than in the catalog itself. It turns out to be
dead easy to implement this: effectively, we just decree that the
index column storage type for NAME is always CSTRING. Because the
two types are effectively binary-compatible as long as you don't
look at the padding, the attached ugly-but-impressively-short patch
seems to accomplish this. It passes the regression tests anyway.
Here are some numbers about the space savings in a virgin database:

CVS HEAD w/patch savings

pg_database_size('postgres') 4439752 4071112 8.3%
pg_relation_size('pg_class_relname_nsp_index') 57344 40960 28%
pg_relation_size('pg_proc_proname_args_nsp_index') 319488 204800 35%

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?

regards, tom lane

Attachment Content-Type Size
unknown_filename text/plain 705 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-06-23 20:14:39 Re: Dept of ugly hacks: eliminating padding space in system indexes
Previous Message Bruce Momjian 2008-06-23 19:50:16 Re: BUG #4027: backslash escaping not disabled in plpgsql