Re: performance on delete the rows from a huge table

Mark D Powell wrote:

> I think Daniel may have misspoken.
>
> If seems to me that no matter how the delete is handled, by rowid or
> key columns, the need for incremental commits is dependend on the
> configuration of the rollback segments/undo tablespace. Either the
> rollback configuration can handle the delete as one transaction or it
> cannot and incremental commits will be necessary. When you delete a
> row the entire row and copies of associated index entries have to be
> written to the rollback segment area. The method of locating the row
> to be deleted by rowid or column values makes no difference.
>
> The transaction would benefit from an index on x1, x2, x3, and x4. If
> these columns should comprise a unique key then the PK constraint
> exceptions clause can be used to locate the duplicate rows as Daniel
> points out.
>
> HTH -- Mark D Powell --

Your words are kind. The comment to which you refer was without substance and I have no idea where it came from other than it somehow lept out from my keyboard.

My point was that I as very doubtful incremental commits were required and to posit they were, before testing and tuning, an unwarranted assumption.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)