On 2013-06-28 11:25:50 -0400, Robert Haas wrote:
> On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> Why does toast_insert_or_update() need to go through all the
> >> rigamarole in toast_datum_differs()? I would have thought that it
> >> could simply treat any external-indirect value as needing to be
> >> detoasted and retoasted, since the destination is the disk anyhow.
> >
> > We could do that, yes. But I think it might be better not to: If we
> > simplify the tuples used in a query to not reference ondisk tuples
> > anymore and we then UPDATE using that new version I would rather not
> > retoast all the unchanged columns.
> >
> > I can e.g. very well imagine that we decide to resolve toasted Datums to
> > indirect Datums during an UPDATE if there are multiple BEFORE UPDATE
> > triggers to avoid detoasting in each and every one of them. Such a tuple
> > will then passed to heap_update...
>
> I must be missing something. At that point, yes, you'd like to avoid
> re-toasting unnecessarily, but ISTM you've already bought the farm.
> Unless I'm misunderstanding the code as written, you'd just end up
> writing the indirect pointer back out to disk in that scenario.
> That's not gonna work...
You didn't misunderstand anything unfortunately. I broke that somewhere
along the road, probably when factoring things out to
toast_datum_differs(). Fixed...
Which shows that we need tests. I've added some using a function in
regress.c that makes all datums indirect. Together with a triggers that
allows some testing.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services