On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule <pavel.steh...@gmail.com> > > wrote: > >> opinion isn't strong in this topic. One or twenty useless detoasting > >> isn't really significant in almost use cases (problem is thousands > >> detoasting). > > > Yeah. Many-times-repeated detoasting is really bad, and this is not > > the only place in the backend where we have this problem. :-( > > Yeah, there's been some discussion of a more general solution, and I > think I even had a trial patch at one point (which turned out not to > work terribly well, but maybe somebody will have a better idea someday). > In the meantime, the proposal at hand seems like a bit of a stop-gap, > which is why I'd prefer to see something with a very minimal code > footprint. Detoast at assignment would likely need only a few lines > of code added in a single place.
What qualifies a patch as stop-gap scale? Pavel's patch is ~60 lines. If adding PLpgSQL_var.should_be_detoasted is your main pain point, testing VARATT_IS_EXTENDED there might be the least-harmful way to avoid it. Saving a few more lines by moving the work to exec_assign_value probably does not justify the associated performance regressions Pavel has cited. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
