On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote: > On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers