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

From Tom Lane
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id 25445.1295970470@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Robert Haas <robertmhaas@gmail.com>)
Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The arguments that were made against this were about maintenance costs
>> and code footprint. �Claims about performance are not really relevant,
>> especially when they're entirely unsupported by evidence.

> How much evidence do you need to the effect that detoasting a value
> that's never used will hurt performance?

I agree that at some microscopic level it will cost something.  What's
not been shown is that there's any significant cost in any real-world
use pattern.  As Pavel said upthread, the main thing here is to get rid
of cases where there are many many repeated detoastings.  Adding an
occasional detoast that wouldn't have happened before is a good tradeoff
for that.  To convince me that we should contort the code to go further,
you need to show that that's more than a negligible cost.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SSI patch version 14
Next
From: Robert Haas
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql