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

From Robert Haas
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id AANLkTimHGViDgj-gMMm=W2TQDjFwfWEyAeBNQ3Kic_3J@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>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Extensions support for pg_dump, patch v27
Next
From: Noah Misch
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql