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
Index: src/backend/catalog/index.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/catalog/index.c,v
retrieving revision 1.300
diff -c -r1.300 index.c
*** src/backend/catalog/index.c 19 Jun 2008 00:46:04 -0000 1.300
--- src/backend/catalog/index.c 23 Jun 2008 19:34:54 -0000
***************
*** 262,267 ****
--- 262,278 ----
ReleaseSysCache(tuple);
}
+
+ /*
+ * For an index on NAME, force the index storage to be CSTRING,
+ * rather than padded to fixed length.
+ */
+ if (to->atttypid == NAMEOID)
+ {
+ to->atttypid = CSTRINGOID;
+ to->attlen = -2;
+ to->attalign = 'c';
+ }
}
return indexTupDesc;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
