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

From Heikki Linnakangas
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id 4D3E760D.9010907@enterprisedb.com
Whole thread Raw
In response to Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 25.01.2011 06:29, Pavel Stehule wrote:
> 2011/1/25 Noah Misch<noah@leadboat.com>:
>> On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
>>> because I am not sure so any complex solution can be done to deadline
>>> for 9.1, I created a patch that is based on Tom ideas - just
>>> explicitly detoast function parameters.
>>
>> I can confirm that, for your original test case, this yields performance
>> comparable to that of your original patch.
>
> I know it :(. I am thinking, so detoasting on usage is better, but I
> am don't know more about Tom or Rober's plans.

Detoasting on first usage, ie. exec_eval_datum(), seems the best to me. 
Compared to detoasting on assignment, it avoids the performance 
regression if the value is never used, and I don't think checking if the 
value is toasted at every exec_eval_datum() call adds too much overhead.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Next
From: Dave Page
Date:
Subject: Re: [RRR] Seeking Mentors for Funded Reviewers