Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql

Noah Misch <noah@leadboat.com> writes:
> On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
>> 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.

Yeah, but they're spread out all over plpgsql, and seem likely to
metastasize to other places --- the additional field that needs to be
initialized is the main culprit.  I'd like a one-spot patch that will
be easy to remove when/if it's no longer needed.

> 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.

I thought about that too, but adding an additional set of tests into
exec_eval_datum isn't free --- that's a hot spot for plpgsql execution.
Doing it in exec_assign_value would be significantly cheaper, first
because it's reasonable to assume that assignments are less frequent
than reads, and second because there's already a test there to detect
pass-by-ref datatypes, as well as a datumCopy() step that could be
skipped altogether when we detoast.
        regards, tom lane