| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] DELETE taking too much memory |
| Date: | 2011-07-08 11:09:17 |
| Message-ID: | CAGTBQpb+2Uv9sZxYBKna6uX1SDsxj9E9CJWjP+_JfeK3s5rLCg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
On Fri, Jul 8, 2011 at 12:48 PM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jose Ildefonso Camargo Tolosa | 2011-07-08 13:37:45 | Re: [PERFORM] DELETE taking too much memory |
| Previous Message | Dean Rasheed | 2011-07-08 10:48:57 | Re: DELETE taking too much memory |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergio Mayoral | 2011-07-08 11:23:09 | execution time for first INSERT |
| Previous Message | Dean Rasheed | 2011-07-08 10:48:57 | Re: DELETE taking too much memory |