On Tue, Jul 29, 2008 at 7:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ivan Zolotukhin" <[EMAIL PROTECTED]> writes:
>> 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 i
"Ivan Zolotukhin" <[EMAIL PROTECTED]> writes:
> 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 w
On Tue, 2008-07-29 at 19:25 +0400, Ivan Zolotukhin wrote:
> Any clues? Can anybody suggest how to debug this? Is it possible to
> get an explain of the query within the trigger?
I bet it's the difference between prepared/not prepared plans. The
trigger prepares the plan without considering the act
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 ps
