RE: Poor Delete performance - Mailing list pgsql-general

From Matthew
Subject RE: Poor Delete performance
Date
Msg-id 183FA749499ED311B6550000F87E206C1FD04D@SRV
Whole thread Raw
In response to Poor Delete performance  (Bill Huff <bhuff@colltech.com>)
Responses Re: Poor Delete performance  (Bill Huff <bhuff@colltech.com>)
Re: Poor Delete performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
    [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.

pgsql-general by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Postgresql.org website search
Next
From: The Hermit Hacker
Date:
Subject: Re: Postgresql.org website search