interesting trigger behaviour in 8.3 - Mailing list pgsql-general

From Ivan Zolotukhin
Subject interesting trigger behaviour in 8.3
Date
Msg-id 751e56400807290825p377c648eg95629ae34399a72a@mail.gmail.com
Whole thread Raw
Responses Re: interesting trigger behaviour in 8.3
Re: interesting trigger behaviour in 8.3
List 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 by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: Date index not used when selecting a date range
Next
From: "John Cheng"
Date:
Subject: What to do after an "ERROR: out of memory"