Re: My "TOAST slicing" patch -explanation

John Gray <jgray@azuli.co.uk> writes:
> Finally, I am aware of the following items which are not covered by the
> patch:

> 1) Efficient updating of parts of a value. This is not trivial[1].

Actually, based on subsequent discussion I now understand that efficient
updating of parts of a TOASTed value is impossible, if by that you mean
rewriting only the modified part.  This is so because TOAST does not
use MVCC, really: it relies on MVCC for the owning tuple to determine
visibility of a tuple value.  The only safe way to update a TOAST item
is to rewrite the whole thing with a new TOAST id number and then
update the owning tuple to reference that new id.

Despite this, it'd be a really good idea to offer functions that allow
applications to write part of a large TOASTed value.  Even if it can't
be as efficient as we'd like, we could still eliminate pushing the rest
of the value back and forth to the client.

> 2) Should the large object interface be handled via TOAST?[2]

Probably not, given the above facts.  We do have MVCC behavior for
partial updates of large objects, and we shouldn't lose it.


Having said all that, I think John's patch for substring extraction is
fine in concept.  I haven't looked at it in detail, but I think we
should review it and expect to apply it (possibly with some cleanups).
        regards, tom lane