I said:
> Ideally we should find a way
> to move tuples into the new table without invoking the TOAST code at
> all, but I'm not sure what that will entail.
I was too tired last night to really think about this. What I had in
mind when I wrote the above was to somehow disable the TOAST machinery
while copying tuples, so that any toasted values in the new heap would
still reference the old toast table. That would avoid "unnecessary"
copying of the toasted datums ... but it looks ugly to do.
This morning, however, I prefer the idea of letting the system build
a new TOAST table along with the new heap, and then simply swapping the
toast-table links along with the relfilenode links. This would be a
trivial addition to Alvaro's patch. The net effect would be that the
contents of the TOAST table would also be re-sorted into the clustered
order, which seems at least potentially a win for access time.
The main downside of this approach is that you'd need enough free disk
space for a new copy of the TOAST table, not only the main table and its
indexes. In some scenarios this will mean a very large increase in the
disk space needed for CLUSTER, since the TOAST table may well out-bulk
its parent by large amounts.
I'm engaged in code review for Alvaro's patch today, and will add the
toast-table link swap as a quick-and-dirty solution. If anyone is
sufficiently swayed by the disk-space issue to investigate doing it the
other way, go right ahead --- we could remove the link swap again if
another solution is offered.
regards, tom lane