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 |
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 |