Re: proposal: add columns created and altered to pg_proc and pg_class

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: proposal: add columns created and altered to pg_proc and pg_class
Date: 2009-04-14 14:45:05
Message-ID: 603c8f070904140745p6f49f16cn901c2d7bb0f80853@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> I though about it too. But I am not sure, if this isn't too
>> complicated solution for simple task. If I thing little bit more -
>> main important is timestamp of last change.
>
> 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.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Devrim GÜNDÜZ 2009-04-14 15:12:30 Re: Regression failure on RHEL 4 w/ PostgreSQL 8.4 beta1
Previous Message Tom Lane 2009-04-14 14:32:00 Re: Unicode string literals versus the world