| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Josh Berkus <josh(at)agliodbs(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: proposal: add columns created and altered to pg_proc and pg_class | 
| Date: | 2009-04-14 16:17:45 | 
| Message-ID: | 12732.1239725865@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
>> Yeah, if it would be too heavy to add a timestamp column or two to
>> pg_class and maybe one or two others, why is it better to add a whole
>> new table to maintain in parallel -- with it's own primary key,
>> foreign keys (or similar integrity enforcement mechanism), etc.
> Making pg_class and pg_proc tables larger hurts run-time performance,
> potentially.  Making a separate table only slows down DDL operations,
> which are much less frequent.
And even more to the point, adding columns to the core system tables
means you pay the performance cost *even when not using the feature*.
We normally expect that inessential features should avoid making a
performance impact on those who have no use for them.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-04-14 16:26:41 | Re: Unicode support | 
| Previous Message | Tom Lane | 2009-04-14 15:54:33 | Re: Unicode string literals versus the world |