Note that whether you have CASCADE or not is not the issue --- if you
are doing a delete in a foreign-key-referenced relation at all, you
are going to have a trigger event per deleted row no matter what the
details of the FK are.
So the best/fastest* way to do this would be to remove the FK
rela
"Worky Workerson" <[EMAIL PROTECTED]> writes:
> On 10/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Well, the memory eating is easy to explain: pending-trigger-event list.
> Is there any way to tune PG to execute such a query, or am I forced to
> forgo the convenience of the "ON DELETE CASCADE" and
On 10/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Worky Workerson" <[EMAIL PROTECTED]> writes:
> When I issue a fairly large DELETE query which has multiple tables
> with FOREIGN KEY CASCADE on them, Postgres eats up *all* the
> memory on my system and the system crashes.
Well, the memory ea
"Worky Workerson" <[EMAIL PROTECTED]> writes:
> When I issue a fairly large DELETE query which has multiple tables
> with FOREIGN KEY CASCADE on them, Postgres eats up *all* the
> memory on my system and the system crashes.
Well, the memory eating is easy to explain: pending-trigger-event lis
When I issue a fairly large DELETE query which has multiple tables
with FOREIGN KEY CASCADE on them, Postgres eats up *all* the
memory on my system and the system crashes. I figure that there are
two problems, one is PG eating up all of the memory, the other is the
system crashing and not te
