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

On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch <noah@leadboat.com> wrote:
> > 1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
> > Essentially Pavel's original patch, only with the check logic moved up from
> > exec_eval_datum() to plpgsql_param_fetch() to avoid bothering a couple other
> > callers that would not benefit. ?Tom and Robert objected to the new bookkeeping.
> 
> I don't understand why it's necessary.  It seems to me that the case
> we're concerned about is when someone is referencing a variable that
> is toasted which they might later want to reference again.  We're
> going to have to notice that the value is toasted and detoast it
> anyway before we can really do anything with it.  So why can't we
> arrange to overwrite the *source* of the data we're fetching with the
> detoasted version?
> 
> I know this is probably a stupid question, but i don't understand the
> code well enough to see why this can't work.

The detoast currently happens well after PL/pgSQL has handed off the datum.
Consider this function, my original benchmark when reviewing this patch:

  CREATE OR REPLACE FUNCTION f(runs int) RETURNS void LANGUAGE plpgsql AS $$
  DECLARE
  	foo	text;
  BEGIN
  	SELECT c INTO foo FROM t;
  	FOR n IN 1 .. runs LOOP
  		PERFORM foo < 'x';
  	END LOOP;
  END
  $$;

Suppose "foo" is toasted.  As the code stands in master, it gets detoasted in
text_lt().  Certainly we won't overwrite the source back in PL/pgSQL from the
detoast point in text_lt().  Pavel's optimization requires that we identify the
need to detoast the datum earlier and do so preemptively.

Thanks,
nm