Re: Delete query takes exorbitant amount of time

From: Karim A Nassar <Karim(dot)Nassar(at)NAU(dot)EDU>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Delete query takes exorbitant amount of time
Date: 2005-03-29 08:48:48
Message-ID: Pine.SOL.4.21.0503290120550.5642-100000@coruscant.cet.nau.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> Each value has 1/13th of the table, which is too many rows per value to
> make an IndexScan an efficient way of deleting rows from the table.

But, the original question was that the delete that was taking a long time
was on a different table. I tried to delete 150 rows from a table with 750
rows, which is FK referenced from this large table. If I understand
correctly, Tom suggested that the length of time was due to a sequential
scan being done on the large table for each value being deleted from the
small one.

(I have no formal training in database administration nor database theory,
so please excuse me if I am being dumb.)

For this FK check, there only need be one referring id to invalidate the
delete. ISTM that for any delete with a FK reference, the index could
always be used to search for a single value in the referring table
(excepting very small tables). Why then must a sequential scan be
performed in this case, and/or in general?

--
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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message PFC 2005-03-29 09:48:34 Re: How to improve db performance with $7K?
Previous Message Kris Jurka 2005-03-29 02:52:36 Re: JDBC best practice