On Wed, 2008-06-18 at 09:45 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > You've not covered the idea that we just alter the execution so we just > > detoast once. > > That's because I already considered and rejected that idea. There's > no very good place to do it. See thread on postgis-devel: > > http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003091.html > > Aside from the problems mentioned there, there's the issue that a lower > plan level doesn't have any way to know whether the value will be needed > at all. We could look for references to the Var but it's entirely > possible that the Var is being passed to some function that doesn't > require a fully detoasted result. It wouldn't do for this > "optimization" to disable the slice-fetch feature...
Agreed. Yet I'm thinking that a more coherent approach to optimising the tuple memory usage in the executor tree might be better than the special cases we seem to have in various places. I don't know what that is, or even if its possible though. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
