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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date: 2011-01-25 15:47:50
Message-ID: 25445.1295970470@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-01-25 16:12:00 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Previous Message Kevin Grittner 2011-01-25 15:41:05 Re: SSI patch version 14