> Tom Lane wrote
> "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.
>
Thanks!
> 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.
>
That could be optimised, but there are advantages to removing TOASTed values
immediately since they are potentially big space hogs, so I'm actually glad
to hear that it works that way.
Best Regards, Simon Riggs
---------------------------(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
