Re: LONG delete with LOTS of FK's

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: LONG delete with LOTS of FK's
Date: 2013-05-10 14:14:53
Message-ID: 4873.1368195293@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Larry Rosenman <ler(at)lerctr(dot)org> writes:
> Any ideas on how to figure out if we ARE getting seqscan check plans,
> and better fix it?

Try an EXPLAIN ANALYZE VERBOSE on something that just deletes one row,
and wait however long it takes. The printout should show how much time
is taken in the implementation trigger for each foreign key. That will
at least nail down which table(s) are causing problems.

A different line of thought is that the EXPLAIN I suggested in
<25119(dot)1367507317(at)sss(dot)pgh(dot)pa(dot)us> isn't an entirely accurate
representation of what a foreign-key checking query is like, because the
check queries are parameterized. You might need to do this instead:

prepare foo(referenced_column_data_type) as
select 1 from <referencing_table> where referencing_column = $1;
explain execute foo(sample_value);

and verify you get a cheap plan for each referencing table.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2013-05-10 14:20:23 Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID
Previous Message Matt Brock 2013-05-10 14:14:09 Deploying PostgreSQL on CentOS with SSD and Hardware RAID