Triggers and transactions - Mailing list pgsql-performance

From Craig James
Subject Triggers and transactions
Date
Msg-id CAFwQ8rcYevFK8tayQ-M7J0ogzdHfuZ4=Jd5qxv4pwexPVcYOww@mail.gmail.com
Whole thread Raw
Responses Re: Triggers and transactions  (Richard Huxton <dev@archonet.com>)
Re: Triggers and transactions  (Rosser Schwarz <rosser.schwarz@gmail.com>)
List pgsql-performance
If I drop and then recreate a trigger inside of a single transaction, how does it affect other processes trying to use the same table?  Can they just merrily go along their way using the table, or will they be blocked by an exclusive lock?

We have a trigger that detects illegal drugs and dangerous chemicals (such as explosives and flammable compounds that can't be shipped by air).  It's implemented as a trigger to ensure that even improperly coded application software can't accidentally let a customer order a prohibited compound.

Unfortunately, the trigger's function is necessarily "heavyweight" and slow.

The drop-and-restore-trigger operation is needed when we're copying data one server to another.  Since the data on the primary source have already been checked, there's no need to let the trigger re-check every row.  When I drop-and-recreate the trigger for the duration of a COPY operation, it speeds the operation from (for example) 30 minutes to 15 seconds.

But if the drop-and-restore-trigger operation blocks all access to the tables, that's a problem.

Thanks,
Craig

pgsql-performance by date:

Previous
From: belal hamed
Date:
Subject: Re: PostgreSQL over internet
Next
From: Richard Huxton
Date:
Subject: Re: Triggers and transactions