Maybe....maybe not.

If I'm going to delete 20% of the rows...and *never* do anything to that table again, I would probably compress the table, rebuild the indexes at pctfree 0 to get the best block utilization I could. This should make scanning the table more efficient and I get more "bang for my buck" with index blocks in the buffer cache.

But if I'm going to load more data in ... then its perhaps a different story. *Depending* on how the data to be deleted is stored, there is a very good chance that all those "deleted" blocks will be simply re-used for the new data coming in. Similarly with index blocks.

I stress *depending* because a lot depends on how the data is distributed within the blocks. Often data inserted in a chronological fashion is deleted in a similar fashion, eg, "load data with a timestamp...delete it when its 2 years". So those older rows will likely occupy common blocks and hence will be completely free'd when you delete. So they'll be re-used just fine without any table/index maintenance required.

But if your delete was (say). "This customer is no longer with us..delete all their records"..then it is possible that you are deleting a 20% chunk of space from *each* block. So those blocks are still in active use (with other customer data), so there is the *potential* that additional data will not re-use that space and hence your table will become larger than it needs to be. In those scenarios, you could consider a shrink operation.