Re: Deleting vs foreign keys

Поиск
Список
Период
Сортировка
Искать
От
WireSpot
Тема
Re: Deleting vs foreign keys
Дата
Msg-id
b2d4b0380510250944m5d369a8bx7c460f2032e3a842@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Deleting vs foreign keys WireSpot <wirespot@gmail.com>
Re: Deleting vs foreign keys Michael Fuhr <mike@fuhr.org>
Re: Deleting vs foreign keys WireSpot <wirespot@gmail.com>
Re: Deleting vs foreign keys Csaba Nagy <nagy@ecircle-ag.com>
Re: Deleting vs foreign keys Martijn van Oosterhout <kleptog@svana.org>
Re: Deleting vs foreign keys WireSpot <wirespot@gmail.com>
Re: Deleting vs foreign keys WireSpot <wirespot@gmail.com>
Re: Deleting vs foreign keys Csaba Nagy <nagy@ecircle-ag.com>
Re: Deleting vs foreign keys WireSpot <wirespot@gmail.com>
Re: Deleting vs foreign keys Richard Huxton <dev@archonet.com>
On 10/25/05, Csaba Nagy  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. :(

That's it then. I'll ask the designers of the application to consider
implementing the background delete, since it's obvious I can't solve
it satisfactorily solely on the DB side.
В списке pgsql-general по дате отправления
От: Zlatko Matic
Дата:
От: Steve Atkins
Дата:
FAQ