Re: proposal: add columns created and altered to pg_proc and pg_class
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: proposal: add columns created and altered to pg_proc and pg_class |
| Дата | |
| Msg-id | 12732.1239725865@sss.pgh.pa.us обсуждение |
| Ответ на | Re: proposal: add columns created and altered to pg_proc and pg_class (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера