"Simon Riggs" <[EMAIL PROTECTED]> writes:
> My answer was this, though this was not thought accurate (on the DELETE
> aspect):
This is correct as far as it goes, but given the question I imagine some
further detail is appropriate:
* When deleting a row that has out-of-line-toasted fields, we must also
find the TOAST row(s) for those fields and mark them deleted. So it is
not strictly true that deleting a wide row has the same cost as deleting
a narrow one: you will have to touch all the pages containing TOAST data
as well.
* UPDATE is indeed basically equivalent to a DELETE and INSERT, with the
sole optimization being that we carry over any unchanged toasted fields.
So in particular, any changed toasted fields will need to be marked
deleted in the TOAST table.
It would be nice to push the TOAST deletions off to become the
responsibility of VACUUM, but I'm not entirely sure how to do that
without giving up the UPDATE optimization of shared values.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
