interesting trigger behaviour in 8.3

Поиск
Список
Период
Сортировка
От Ivan Zolotukhin
Тема interesting trigger behaviour in 8.3
Дата
Msg-id 751e56400807290825p377c648eg95629ae34399a72a@mail.gmail.com
обсуждение исходный текст
Ответы Re: interesting trigger behaviour in 8.3  (Csaba Nagy <nagy@ecircle-ag.com>)
Re: interesting trigger behaviour in 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Hello,

We came accross interesting behaviour of the update statement inside
an after insert or update trigger in PostgreSQL 8.3.1. Briefly, the
update run within one line trigger function takes always 1.5 sec
whereas exactly the same update hitting the same rows takes always 1ms
if run from the psql terminal.

In pseudo code it looks like the following. There are 2 tables, empty
abstract_table with 3 columns (id, col1, col2) and many tables (e.g.
inherited_table1_with_data) that inherit abstract_table.
Constraint_exclusion is set up on id column and works perfectly. So
we've got update like this

UPDATE abstract_table SET col1 = 1, col2 = 2 WHERE id = 12345;

that takes too long when run from trigger (fired on any third table)
and takes 1ms if run literally with all the same constants from
terminal. However there's one more issue with that. If we change
update within trigger to eliminate constraint_exclusion check and
point it directly to child table with data:

UPDATE inherited_table1_with_data SET col1 = 1, col2 = 2 WHERE id = 12345;

trigger works perfectly doing everything for 1ms as in terminal.

Any clues? Can anybody suggest how to debug this? Is it possible to
get an explain of the query within the trigger?

--
Regards,
 Ivan

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

Предыдущее
От: "Scott Marlowe"
Дата:
Сообщение: Re: Date index not used when selecting a date range
Следующее
От: "John Cheng"
Дата:
Сообщение: What to do after an "ERROR: out of memory"