From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard van den Berg <richard(dot)vandenberg(at)trust-factory(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Foreign key slows down copy/insert |
Date: | 2005-04-14 16:11:41 |
Message-ID: | 20050414090931.P42874@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 14 Apr 2005, Tom Lane wrote:
> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> 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
Yeah, but there's a potentially large middle ground where neither our
current plan nor check the entire table is particularly good for that we
might be able to handle better. It'd be nice to also fall back to check
the entire table for even larger changes.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-14 16:20:47 | Re: speed of querry? |
Previous Message | Dawid Kuroczko | 2005-04-14 16:04:02 | Re: speed of querry? |