On Tue, Jan 25, 2011 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Well, what if somebody calls the function like this?
SELECT foo(a, b) FROM huge_table
This is not a particularly uncommon thing to do, and it might easily
be the case that foo accesses b for some values of a but not all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
