Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
От | Alvaro Herrera |
---|---|
Тема | Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT |
Дата | |
Msg-id | 20090405023152.GC4406@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT |
Список | pgsql-hackers |
Robert Haas escribió: > On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> Per previous discussion. > >> http://archives.postgresql.org/message-id/8066.1229106059@sss.pgh.pa.us > >> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc68141133957c1@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
В списке pgsql-hackers по дате отправления: