Hi Michael!
Yes, I know about relation rewrite and have already thought about how
we can avoid excessive storage of toastrelid and do not spoil rewrite,
still do not have a good enough solution.
> You have some interesting points around
> detoast_external_attr() and detoast_attr_slice(), as far as I can see.
> One point of the on-disk TOAST refactoring is that we should be able
> to entirely avoid this level of redirection. I get that this is a
> POC, of course, but it provides pointers that what I've done may not
> be sufficient in terms of extensibility so that seems worth digging
> into.
I'm currently re-visiting our TOAST API patch set, there are some
good (in terms of simplicity and lightweightness) proposals, will mail
later.
Some more thoughts on TIDs:
TIDs could be stored as a list instead of a chain (as Hannu proposes
in his design). This allows batch operations and storage optimization
'cause TID lists are highly compressible, but significantly complicates
the code responsible for chunk processing.
Also, Toast pointer in current state must store raw size and external
size - these two are used by the executor, and we cannot get rid
of them so lightly.
Vacuuming such a table would be a pain in the ass, we have to
somehow prevent bloating tables with a high update rate.
Also, current toast mechanics is insert-only, it does not support
updates (just to remind - the whole toasted value is marked dead
and new one is inserted during update), this is a subject to change.
And logical replication, as I mentioned earlier, does not have any
means for replicating toast diffs.
