On Mon, Apr 21, 2014 at 10:57:34AM -0400, Tom Lane wrote:
> Noah Misch <noah@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.
If that's its worst drawback, it's excellent.
> 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.
I maintain that the potential slowdown is too great to consider adopting that
for the sake of a cleaner patch. Your last message examined a 67% performance
regression. The strategy you're outlining now can slow a query by 1,000,000%.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com