Re: extensible external toast tuple support

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: extensible external toast tuple support
Дата
Msg-id CA+TgmoYJuLYvQx4o8qz5m37C8rTcEsRqUDZL7kLbC+G8_R706g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: extensible external toast tuple support  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: extensible external toast tuple support  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
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...

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: enable new error fields in plpgsql (9.4)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls