From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Lewis <mark(dot)lewis(at)mir3(dot)com> |
Cc: | Brian Choate <brianc(at)nimblefish(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Poor performance of delete by primary key |
Date: | 2005-09-06 17:42:59 |
Message-ID: | 19191.1126028579@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mark Lewis <mark(dot)lewis(at)mir3(dot)com> writes:
> I had a similar problem, so I downloaded 8.1 from CVS, ran it on a
> relatively gnarly dev workstation, imported a dump of my 8.0 database,
> and ran my troublesome queries with the new EXPLAIN ANALYZE.
> This process took about an hour and worked great, provided that you've
> actually named your foreign key constraints. Otherwise, you'll find out
> that there's a trigger for a constraint called $3 that's taking up all
> of your time, but you won't know what table that constraint is on.
But at least you've got something you can work with. Once you know the
name of the problem trigger you can look in pg_trigger to see which
other table it's connected to. Try something like
select tgname, tgconstrrelid::regclass, tgargs from pg_trigger
where tgrelid = 'mytable'::regclass;
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Carlos Henrique Reimer | 2005-09-06 20:34:12 | log_duration times |
Previous Message | Merlin Moncure | 2005-09-06 17:11:18 | Re: insert performance for win32 |