Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Дата
Msg-id AANLkTikEWWaz_+5Ym-OMMLRVnymCzP=UXBeDpFQsKw3P@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Noah Misch <noah@leadboat.com>)
Ответы Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch <noah@leadboat.com> wrote:
> 1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
> Essentially Pavel's original patch, only with the check logic moved up from
> exec_eval_datum() to plpgsql_param_fetch() to avoid bothering a couple other
> callers that would not benefit.  Tom and Robert objected to the new bookkeeping.

I don't understand why it's necessary.  It seems to me that the case
we're concerned about is when someone is referencing a variable that
is toasted which they might later want to reference again.  We're
going to have to notice that the value is toasted and detoast it
anyway before we can really do anything with it.  So why can't we
arrange to overwrite the *source* of the data we're fetching with the
detoasted version?

I know this is probably a stupid question, but i don't understand the
code well enough to see why this can't work.

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


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: ALTER TYPE 2: skip already-provable no-work rewrites
Следующее
От: Noah Misch
Дата:
Сообщение: Re: ALTER TYPE 2: skip already-provable no-work rewrites