interesting trigger behaviour in 8.3

From: "Ivan Zolotukhin" <ivan(dot)zolotukhin(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: interesting trigger behaviour in 8.3
Date: 2008-07-29 15:25:08
Message-ID: 751e56400807290825p377c648eg95629ae34399a72a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John Cheng 2008-07-29 15:29:24 What to do after an "ERROR: out of memory"
Previous Message Scott Marlowe 2008-07-29 14:18:31 Re: Date index not used when selecting a date range