Re: ToDo List Item - System Table Index Clustering - Mailing list pgsql-hackers

From Simone Aiken
Subject Re: ToDo List Item - System Table Index Clustering
Date
Msg-id 00ab01cbb81f$a5eeaad0$f1cc0070$@ulfheim.net
Whole thread Raw
In response to Re: ToDo List Item - System Table Index Clustering  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ToDo List Item - System Table Index Clustering  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
>
>I seem to recall some muttering about teaching genbki to extract such
comments from the SGML sources or perhaps the C header files.  I tend to
agree though that it would be a lot >more work than it's worth.  And as you
say, pg_description entries aren't free.
>

I know I can't do all of the work, any submission requires review etc, but
it is worth it to me provided it does no harm to the codebase.

So the only outstanding question is the impact of increased size.

In my experience size increases related to documentation are almost always
worth it.  So I'm prejudiced right out of the gate.  I was wondering if
every pg_ table gets copied out to every database ..  if there is already a
mechanism for not replicating all of them we could utilize views or
re-writes rules to merge a single copy of catalog comments in a separate
table with each deployed database's pg_descriptions.  

If all catalog descriptions were handled this way it would actually decrease
the size of a deployed database ( by 210K? ) by absorbing the
pg_descriptions that are currently being duplicated.   Since users shouldn't
be messing with them anyway and they are purely for humans to refer to - not
computers to calculate explain plans with -  there shouldn't be anything
inherently wrong with moving static descriptions out of user space.  In
theory at least.  


-Simone Aiken





pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: ALTER TYPE 1: recheck index-based constraints
Next
From: Noah Misch
Date:
Subject: Re: Snapshot synchronization, again...