On Tue, Jan 25, 2011 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
