> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly