Robert Haas escribió: > On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> Per previous discussion. > >> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us > >> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail.gmail.com > > > > I'm not thrilled about adding a column to pg_attribute for this. > > Isn't there some way of keeping it in pg_statistic? > > I don't like the idea of keeping it in pg_statistic. Right now, all > of the data in pg_statistic is transient, so you could theoretically > truncate the table at any time without losing anything permanent.
Maybe use a new catalog? > What is the specific nature of your concern? I thought about the > possibility of a distributed performance penalty that might be > associated with enlarging pg_attribute, but increasing the size of a > structure that is already 112 bytes by another 4 doesn't seem likely > to be significant, especially since we're not crossing a power-of-two > boundary. FWIW it has been said that whoever is concerned about pg_attribute bloat should be first looking at getting rid of the redundant entries for system columns, for each and every table. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
