On Sun, Feb 6, 2011 at 8:47 AM, Noah Misch <n...@leadboat.com> wrote: > 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().
Right, that much seems obvious... > Pavel's optimization requires that we identify the > need to detoast the datum earlier and do so preemptively. I guess I need to look at the patch more. I'm failing to understand why that can't be done within one or two functions, without passing around a new piece of state. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
