Re: PostgreSQL Write Performance

Поиск
Список
Период
Сортировка
От Tim Uckun
Тема Re: PostgreSQL Write Performance
Дата
Msg-id 855e4dcf1001051830x1612f600idd52387d7e73aa7a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL Write Performance  (Craig Ringer <craig@postnewspapers.com.au>)
Ответы Re: PostgreSQL Write Performance  (Craig Ringer <craig@postnewspapers.com.au>)
Re: PostgreSQL Write Performance  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-general
> I, for one, would loudly and firmly resist the addition of such a
> feature. Almost-as-fast options such as intelligent re-checking of

Even if it was not the default behavior?

>
> If you really want to do that, look at the manual for how to disable
> triggers, but understand that you are throwing away the database's data
> integrity protection by doing it.
>

I guess it's a matter of philosophy. I kind of think as the DBA I
should be the final authority in determining what is right and wrong.
It's my data after all. Yes I would expect pg to perform every check I
specify and execute every trigger I write but if I want I should be
able to bypass those things "just this once".

As you point out I can already do this by manually going through and
disabling every trigger or even dropping the triggers. Many people
have said I could drop the constraints and re-set them up.  The fact
that the COPY command does not have a convenient way for me to do this
doesn't prevent me from "shooting myself in the foot" if I want to.
It would just be a flag. If you want you can enable it, if you don't
they no harm no foul.

Anyway this is getting offtopic. I got my question answered. COPY does
not do this. If I want to do it I have to manually iterate through all
the triggers and disable them or drop them before running copy.

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

Предыдущее
От: Seb
Дата:
Сообщение: Re: conditional rule not applied
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: PostgreSQL Write Performance