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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: proposal: add columns created and altered to pg_proc and pg_class
Дата
Msg-id 603c8f070904140745p6f49f16cn901c2d7bb0f80853@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: add columns created and altered to pg_proc and pg_class  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: proposal: add columns created and altered to pg_proc and pg_class  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: proposal: add columns created and altered to pg_proc and pg_class  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Pavel Stehule <pavel.stehule@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Unicode string literals versus the world
Следующее
От: Devrim GÜNDÜZ
Дата:
Сообщение: Re: Regression failure on RHEL 4 w/ PostgreSQL 8.4 beta1