There's little different about what happens during DELETE. Close out any open sessions you might have with the unfinished transaction. Now let's start another transaction to delete a row:
Once again, if you look at this table from another session, then, because it's not been committed yet, the row deleted here will still be there, just with an xmax value set:
Only in the first session has the row been deleted. This brings us to a second form of visibility that needs to be considered: when a row is deleted, it can't actually go away until any session that might need to see the row has ended. So, when you commit a delete, it doesn't actually change the record itself. Instead, it updates the visibility information around that row to say "this is deleted and may not be visible everywhere", and then each client who checks it will need to make that decision for itself. These are called dead rows in the database; regular rows are described as live.
Another interesting thing to note here is that the way this row looks is exactly like the one left behind by an UPDATE statement; it's just another row with an xmax set waiting for a commit, after which it can be removed. Because of MVCC, whether you update or delete a row, you get the same form of dead row left over at the end. The only exception is if you are updating in a situation where the HOT technique in the database can be used to speed your update, something covered in the following section. That may be a bit less expensive.