Re: Perfromance of SQL DELETE vs clrpfm

[CRPence <CRPbottle@xxxxxxxxx>]

On 10/14/10 8:48 AM, Mark S. Waterbury wrote:
> CLRPFM deletes the data space for a physical file member and replaces
> it with a new empty one, and invalidates/clears any access paths
> (indexes) over this PF. <<SNIP>>
>
> Running an SQL delete will actually delete each row, row by row
> <<SNIP>> Also, if the file is defined with REUSEDLT(*NO), you will
> have a bunch of deleted records taking up disk space, until you run
> a RGZPFM.
>
> <<SNIP>>

  Just FWiW...

  The member remains the same object, as does the dataspace.  That can 
be confirmed by DMPOBJ showing the same address of the *MEM and the 
*QDDS objects both before and then after the CLRPFM request.  The 
dataspace object is truncated by a request to clear the PF member; the 
individual data segments [those addresses not visible in the dump 
object] returned to the system\ASP.

  The member.data will have the deleted rows remaining [and thus taking 
up disk space, until reorganize PFM] irrespective of the reuse-deleted 
attribute setting; except of course, with the capability of the SQL 
DELETE to implement using the "clear" feature [Fast Delete support] 
which was already noted in a response by Eric DeLong.

Regards, Chuck