Thread: Deferred constraint and delete performance

Hi,

I am trying to improve delete performance on a database with several
foreign keys between relations that have 100M or so rows.

Until now, I have manually disabled the triggers, done the delete, and
re-enabled the triggers.

This works, but I have to do that when I am sure no other user will
access the database...

I am wondering if deferring foreign key constraints (instead of
disableing them) would increase performance, compared to non deferred
constraints (and compared to disableing the constraints, but I guess no
in this case).

Thanks,

Franck

Franck Routier <franck.routier@axege.com> writes:
> I am wondering if deferring foreign key constraints (instead of
> disableing them) would increase performance, compared to non deferred
> constraints

No, it wouldn't make any noticeable difference AFAICS.  It would
postpone the work from end-of-statement to end-of-transaction,
but not make the work happen any more (or less) efficiently.

            regards, tom lane

On Wednesday 10 February 2010 15:56:40 Tom Lane wrote:
> Franck Routier <franck.routier@axege.com> writes:
> > I am wondering if deferring foreign key constraints (instead of
> > disableing them) would increase performance, compared to non deferred
> > constraints
>
> No, it wouldn't make any noticeable difference AFAICS.  It would
> postpone the work from end-of-statement to end-of-transaction,
> but not make the work happen any more (or less) efficiently.
It could make a difference if the transaction is rather long and updates the
same row repeatedly because of better cache usage. But I admit thats a bit of
a constructed scenario (where one likely would get into trigger-queue size
problems as well)

Andres