Re: Materializing a sequential scan

From: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Materializing a sequential scan
Date: 2005-10-26 23:22:19
Message-ID: 20051026232219.GA6390@uio.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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/

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Sidar López Cruz 2005-10-26 23:47:31 performance on query
Previous Message Tom Lane 2005-10-26 23:18:37 Re: Performance issues with custom functions