Utility functions for enabling/disabling fkey triggers

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: pgsql-performance(at)postgresql(dot)org
Subject: Utility functions for enabling/disabling fkey triggers
Date: 2008-03-10 09:12:52
Message-ID: 47D4FB94.9080601@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi all

I've just spent some time working with PostgreSQL 8.3 trying to get a 90
minute job to run in a reasonable amount of time, and in the process
I've come up with something that I thought others might find useful.

Attached is a pair of PL/PgSQL functions that enable/disable the
triggers associated with a given foreign key constraint. They use the
system catalogs to obtain all the required information about the
involved tables. A fairly fast consistency check is performed before
re-enabling the triggers.

As it turns out I don't need it after all, but I though that others
doing really large data imports might given messages like:

http://archives.postgresql.org/pgsql-performance/2003-03/msg00157.php

I wrote it because I was frustrated with the slow execution of the ALTER
TABLE ... ADD CONSTRAINT ... FOREIGN KEY statements I was running to
rebuild the foreign key constraints on some of my tables after some bulk
imports. Leaving the constraints enabled was resulting in execution time
that increased for every record inserted, and rebuilding them after the
insert wasn't much faster.

Unfortunately it turns out that the issue wasn't with the way ALTER
TABLE ... ADD CONSTRAINT ... FOREIGN KEY was doing the check, as the
integrity check run by those functions is almost as slow as the ALTER
TABLE in the context of the transaction they're run in - and both run in
< 1 second outside of a transaction context or in a separate transaction.

Oh well, maybe the code will be useful to somebody anyway.

--
Craig Ringer

Attachment Content-Type Size
disable_triggers.sql text/x-sql 7.7 KB

Browse pgsql-performance by date

  From Date Subject
Next Message Craig Ringer 2008-03-10 09:55:59 Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Previous Message Greg Smith 2008-03-10 05:10:21 Re: UPDATE 66k rows too slow