| 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: | Whole Thread | Raw Message | 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 |