Re: [GENERAL] DELETE taking too much memory - Mailing list pgsql-performance

From Claudio Freire
Subject Re: [GENERAL] DELETE taking too much memory
Date
Msg-id CAGTBQpb+2Uv9sZxYBKna6uX1SDsxj9E9CJWjP+_JfeK3s5rLCg@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] DELETE taking too much memory  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-performance
On Fri, Jul 8, 2011 at 12:48 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> Yes, it's the same issue that affects deferrable PK and FK
> constraints, but even non-deferrable FKs use AFTER ROW triggers that
> suffer from this problem. These triggers don't show up in a "\d" from
> psql, but they are there (try select * from pg_trigger where
> tgconstrrelid = 't1'::regclass) and because they fire AFTER rather
> than BEFORE, queuing up large numbers of them is a problem.

I would imagine an "easy" solution would be to "compress" the queue by
inserting a single element representing all rows of row version id X.

Ie: a delete or update will need to check all the row versions it
creates with its txid, this txid could be used to represent the rows
that need checking afterwards right?

pgsql-performance by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [GENERAL] DELETE taking too much memory
Next
From: Sergio Mayoral
Date:
Subject: execution time for first INSERT