On Thu, 2005-03-24 at 19:52 -0500, Tom Lane wrote:
> Karim Nassar <Karim.Nassar@acm.org> writes:
> > Here is the statement:
>
> > orfs=# explain analyze DELETE FROM int_sensor_meas_type WHERE
> > id_meas_type IN (SELECT * FROM meas_type_ids);
> > QUERY PLAN
> >
-----------------------------------------------------------------------------------------------------------------------------
> > Hash Join (cost=11.53..42.06 rows=200 width=6) (actual
> > time=1.564..2.840 rows=552 loops=1)
> > ...
> > Total runtime: 2499616.216 ms
> > (7 rows)
>
> Notice that the actual join is taking 2.8 ms. The other ~40 minutes
is
> in operations that we cannot see in this plan, but we can surmise are
ON
> DELETE triggers.
There are no DELETE triggers (that I have created).
> > Where do I go from here?
>
> Look at what your triggers are doing. My private bet is that you have
> unindexed foreign keys referencing this table, and so each deletion
> forces a seqscan of some other, evidently very large, table(s).
Almost. I have a large table (6.3 million rows) with a foreign key
reference to this one (which has 749 rows), however it is indexed.
I deleted the fk, ran the delete, then recreated the foreign key in
about 15 seconds. Thanks!
Problem now is: this referencing table I expect to grow to about 110
million rows in the next 2 months, then by 4 million rows per month
thereafter. I expect that the time for recreating the foreign key will
grow linearly with size.
Is this just the kind of thing I need to watch out for? Any other
suggestions for dealing with tables of this size? What can I do to my
indexes to make them mo' betta?
--
Karim Nassar
Department of Computer Science
Box 15600, College of Engineering and Natural Sciences
Northern Arizona University, Flagstaff, Arizona 86011
Office: (928) 523-5868 -=- Mobile: (928) 699-9221
