Noah Misch <n...@leadboat.com> writes: > I wonder how it would work out to instead delay this new detoast effort until > toast_insert_or_update().
That would require toast_insert_or_update() to know about every container datatype. I doubt it could lead to an extensible or maintainable solution. I'm actually planning to set this patch on the shelf for a bit and go investigate the other alternative, ie, not generating composite Datums containing toast pointers in the first place. We now know that the idea that we aren't going to take performance hits *somewhere* is an illusion, and I still suspect that the other way is going to lead to a smaller and cleaner patch. The main performance downside for plpgsql might be addressable by making sure that plpgsql record variables fall on the "heap tuple" rather than the "composite Datum" side of the line. I'm also quite concerned about correctness: I don't have a lot of confidence that this patch has closed every loophole with respect to arrays, and it hasn't even touched ranges or any of the related one-off bugs that I believe exist. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers