| From: | Matthew <matt(at)ctlno(dot)com> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bill Huff <bhuff(at)colltech(dot)com> |
| Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | RE: Poor Delete performance |
| Date: | 2001-03-12 18:23:41 |
| Message-ID: | 183FA749499ED311B6550000F87E206C1FD04D@SRV |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | The Hermit Hacker | 2001-03-12 18:37:29 | Re: Postgresql.org website search |
| Previous Message | The Hermit Hacker | 2001-03-12 18:19:18 | Re: Postgresql.org website search |