From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Gray <jgray(at)azuli(dot)co(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: My "TOAST slicing" patch -explanation |
Date: | 2002-02-24 18:52:41 |
Message-ID: | 2883.1014576761@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Gray <jgray(at)azuli(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-02-24 19:25:46 | Re: My "TOAST slicing" patch -explanation |
Previous Message | Tom Lane | 2002-02-24 18:40:28 | Re: patch queue |