Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id AANLkTikkYL1pgaT2F7yTvPcS9D_nbT9ahU3yrHYdu8+g@mail.gmail.com
Whole thread Raw
In response to Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
2011/2/8 Noah Misch <noah@leadboat.com>:
> On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
>> 2011/2/8 Noah Misch <noah@leadboat.com>:
>> > 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
>>
>> I tested this in situation when Datum is detoasted on usage, not in
>> assignment. So impact will be less.
>
> Robert spoke of doing it on usage (exec_eval_datum()) too, though.
>

I am blind, sorry

Regards

Pavel


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Add ENCODING option to COPY
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI patch version 14