| From: | Richard Huxton <dev(at)archonet(dot)com> |
|---|---|
| To: | WireSpot <wirespot(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Deleting vs foreign keys |
| Date: | 2005-10-25 17:11:49 |
| Message-ID: | 435E6755.9030008@archonet.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
WireSpot wrote:
> On 10/25/05, Csaba Nagy <nagy(at)ecircle-ag(dot)com> wrote:
>
>>I guess your master table has a considerable tree of child records for
>>each deleted record, that's why the deletion takes so long. We have this
>>situation too on top level object deletion. Our solution is to make it
>>asynchronous, i.e. the user requests it and then a background job does
>>it. There's no way to make such deletes blazing fast.
>
>
> It's a bit puzzling, frankly, to see a nice example of engineering
> (which is what I consider a consistent DB design) foiled by a
> performance and practical issue. :(
Don't kid yourself that there's a solution to this. If you've got a site
with a lot of data in a lot of dependent tables, then have to expend a
certain amount of effort to delete them.
Anything PG did to make your delete faster would almost certainly slow
down updates/inserts/selects. Managing a lot of data takes a lot of effort.
--
Richard Huxton
Archonet Ltd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marek Lewczuk | 2005-10-25 17:26:51 | the best way to catch table modification |
| Previous Message | Andreas Seltenreich | 2005-10-25 17:02:02 | Re: STL problem in stored procedures |