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: | Raw Message | Whole Thread | 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 |