Re: Foreign key slows down copy/insert

From: Tom Lane
Subject: Re: Foreign key slows down copy/insert
Date: ,
Msg-id: 742.1113491145@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Foreign key slows down copy/insert  (Stephan Szabo)
Responses: Re: Foreign key slows down copy/insert  (Stephan Szabo)
List: pgsql-performance

Tree view

Foreign key slows down copy/insert  (Richard van den Berg, )
 Re: Foreign key slows down copy/insert  (Christopher Kings-Lynne, )
  Re: Foreign key slows down copy/insert  (Richard van den Berg, )
   Re: Foreign key slows down copy/insert  (Christopher Kings-Lynne, )
    Re: Foreign key slows down copy/insert  (Richard van den Berg, )
     Re: Foreign key slows down copy/insert  (Christopher Kings-Lynne, )
      Re: Foreign key slows down copy/insert  (Richard van den Berg, )
       Re: Foreign key slows down copy/insert  (Christopher Kings-Lynne, )
        Re: Foreign key slows down copy/insert  (Marko Ristola, )
      Re: Foreign key slows down copy/insert  (Tom Lane, )
   Re: Foreign key slows down copy/insert  (Stephan Szabo, )
    Re: Foreign key slows down copy/insert  (Tom Lane, )
     Re: Foreign key slows down copy/insert  (Stephan Szabo, )
 Re: Foreign key slows down copy/insert  (PFC, )
  Re: Foreign key slows down copy/insert  (Richard van den Berg, )
  Re: Foreign key slows down copy/insert  (PFC, )
   Re: Foreign key slows down copy/insert  (Richard van den Berg, )
    Re: Foreign key slows down copy/insert  (Christopher Kings-Lynne, )
     Re: Foreign key slows down copy/insert  (Richard van den Berg, )
      Re: Foreign key slows down copy/insert  (Tom Lane, )
       Re: Foreign key slows down copy/insert  (Richard van den Berg, )

Stephan Szabo <> writes:
> ... At some point, if we can work out how to do all the semantics
> properly, it'd probably be possible to replace the insert type check with
> a per-statement check which would be somewhere in between.  That requires
> access to the affected rows inside the trigger which I don't believe is
> available currently.

Not necessarily.  It occurs to me that maybe what we need is "lossy
storage" of the trigger events.  If we could detect that the queue of
pending checks for a particular FK is getting large, we could discard
the whole queue and replace it with one entry that says "run the
wholesale check again when we are ready to fire triggers".  I'm not
sure how to detect this efficiently, though --- the trigger manager
doesn't presently know anything about FKs being different from
any other kind of trigger.

            regards, tom lane


pgsql-performance by date:

From: "Joshua D. Drake"
Date:
Subject: Re: How to improve db performance with $7K?
From: "Joel Fradkin"
Date:
Subject: Re: speed of querry?