Re: extensible external toast tuple support

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Subject: Re: extensible external toast tuple support
Date: 2013-06-28 15:25:50
Message-ID: CA+TgmoYJuLYvQx4o8qz5m37C8rTcEsRqUDZL7kLbC+G8_R706g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund <andres(at)2ndquadrant(dot)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...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-06-28 15:28:02 Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Previous Message Robert Haas 2013-06-28 15:22:09 Re: changeset generation v5-01 - Patches & git tree