Re: Materializing a sequential scan

On Wed, Oct 26, 2005 at 07:06:15PM -0400, Tom Lane wrote:
> AFAICS, subplan_is_hashable() is testing the same conditions in 7.4 and
> HEAD, so this isn't clear.  Want to step through it and see where it's
> deciding not to hash?

Line 639, ie.:

635                 if (!optup->oprcanhash || optup->oprcom != opid ||
636                         !func_strict(optup->oprcode))
637                 {
638                         ReleaseSysCache(tup);
639                         return false;
640                 }

gdb gives

(gdb) print *optup
$2 = {oprname = {
    data = "\220Ü2\b\000\000\000\000\000\000\000\000\005\230-\b", '\0' <repeats 16 times>,
"X\0305\b\020\000\000\000\000\000\000\000ئ>\b\020\000\000\000\000\000\000\000ð\213>\b\020\000\000",alignmentDummy =
137550992},oprnamespace = 137542808, oprowner = 64, oprkind = 8 '\b', oprcanhash = -112 '\220', oprleft = 2, oprright =
0, 
  oprresult = 0, oprcom = 0, oprnegate = 0, oprlsortop = 0, oprrsortop = 0, oprltcmpop = 0, oprgtcmpop = 0, oprcode =
0,oprrest = 0, oprjoin = 0} 

(gdb) print opid
$3 = 2373

So it's complaining about the optup->oprcom != opid part. This is of course
on the third run through the loop, ie. it's complaining about the argument
which is run through the function kortsys2.effektiv_dato(date)... For
convenience, I've listed it again here:

CREATE FUNCTION kortsys2.effektiv_dato(date) RETURNS date
AS
        'SELECT CASE WHEN $1 < CURRENT_DATE THEN CURRENT_DATE ELSE $1 END'
LANGUAGE SQL STABLE;

/* Steinar */
--
Homepage: http://www.sesse.net/