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 AANLkTimHGViDgj-gMMm=W2TQDjFwfWEyAeBNQ3Kic_3J@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  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
>> So
>> can we just get rid of should_be_detoasted, and have exec_eval_datum()
>> or its callers instead test:
>>
>> !var->isnull && var->datatype->typbyval && var->datatype->typlen == -1
>> && VARATT_IS_EXTENDED(var->value)
>
> FWIW, this is what I meant by option 2 in my summary.
>
>> I haven't tested this, but it's not clear that'd be measurably slower
>> than checking a single Boolean.
>
> Pavel benchmarked this or something close, measuring a performance loss:
> http://archives.postgresql.org/message-id/AANLkTikDHekc9r38w2ttzoMDr8vDaVAnr3LhqfJkEuL9@mail.gmail.com
>
> Tom also expressed concern over performance:
> http://archives.postgresql.org/message-id/24266.1295462892@sss.pgh.pa.us
>
> Not sure what's next.

Well, Pavel's subsequent reply suggested that he didn't test exactly
this thing, so maybe there's hope.

Or maybe not.  If Tom thought one branch inside exec_eval_datum() was
going to be too expensive, four isn't going to be better.

But I think we're out of time to work on this for this cycle.  Even if
my latest idea is brilliant (and it may not be), we still have to test
it in a variety of cases and get consensus on it, which seems like
more than we can manage right now.  I think it's time to mark this one
Returned with Feedback, or perhaps Rejected would be more accurate in
this instance.

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


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Extensions support for pg_dump, patch v27
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql