Just for everyones information. I removed the foreign key constraint
that was on the table and was able to delete about 190K records in
just over 5 seconds. That is much more like it. B^)
This does appear to be an interesting *feature* with the way that
constraints are handled.
--
Bill
On Mon, Mar 12, 2001 at 12:23:41PM -0600, Matthew wrote:
> [snip]
>
> > This needs to be improved (if we can't get rid of the lookup completely,
> > maybe use a hash table instead of sequential scan?) but it's much too
> > late to consider fixing it for 7.1 :-(.
> >
> > Actually, though, it might be even stupider than that: it looks like
> > the queue should only be searched if the tuple being deleted was
> > inserted/modified earlier in the same transaction. Assuming that that
> > doesn't apply to Bill's case, the only thing I can see that could be
> > causing O(N^2) behavior is the lappend() in deferredTriggerAddEvent.
> > That's simple enough that we *could* fix it for 7.1 ...
> >
> This would be a welcome improvement. I have for a long time noticed
> very slow delete performance when deleting a large number of records in one
> command. I can give more detail if so desired.
--
_____
/ ___/___ | Bill Huff / bhuff@colltech.com
/ /__ __/ | Voice: (512) 263-0770 x 262
/ /__/ / | Fax: (512) 263-8921
\___/ /ollective | Pager: 1-800-946-4646 # 1406217
\/echnologies |------[ http://www.colltech.com ] ------
