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
|
Список | 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 по дате отправления: