On Sun, 2002-02-24 at 23:52, Tom Lane wrote:
> 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.
Do TOAST tables participate in WAL ?
> 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.
Can't we still devise some way to reuse the chunks that did not change ?
With some kind of double indirection and associated bookkeeping perhaps?
> 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.
I guess this can be already done with creative use of substring() and ||
> > 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.
It would feel "cleaner" to have one representation for LOs - can't TOAST
just be made to participate in MVCC?
We could restict WAL of LOs to UPDATES only (and force fsync on TOAST
FILE after INSERT) just to conserve log space.
----------------
Hannu
