Re: Deleting vs foreign keys

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

In response to

Browse pgsql-general by date

  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