Horton

Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2011-01-25T07:04:45Z
Lists: 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