pgsql: Teach planner and executor to handle ScalarArrayOpExpr as an - Mailing list pgsql-committers

From tgl@svr1.postgresql.org (Tom Lane)
Subject pgsql: Teach planner and executor to handle ScalarArrayOpExpr as an
Date
Msg-id 20051125194750.00FB3D6FA6@svr1.postgresql.org
Whole thread Raw
List pgsql-committers
Log Message:
-----------
Teach planner and executor to handle ScalarArrayOpExpr as an indexable
qualification when the underlying operator is indexable and useOr is true.
That is, indexkey op ANY (ARRAY[...]) is effectively translated into an
OR combination of one indexscan for each array element.  This only works
for bitmap index scans, of course, since regular indexscans no longer
support OR'ing of scans.  There are still some loose ends to clean up
before changing 'x IN (list)' to translate as a ScalarArrayOpExpr;
for instance predtest.c ought to be taught about it.  But this gets the
basic functionality in place.

Modified Files:
--------------
    pgsql/src/backend/executor:
        nodeBitmapIndexscan.c (r1.11 -> r1.12)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeBitmapIndexscan.c.diff?r1=1.11&r2=1.12)
        nodeIndexscan.c (r1.106 -> r1.107)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeIndexscan.c.diff?r1=1.106&r2=1.107)
    pgsql/src/backend/optimizer/path:
        clausesel.c (r1.75 -> r1.76)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/clausesel.c.diff?r1=1.75&r2=1.76)
        indxpath.c (r1.193 -> r1.194)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/indxpath.c.diff?r1=1.193&r2=1.194)
    pgsql/src/backend/optimizer/plan:
        createplan.c (r1.203 -> r1.204)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/createplan.c.diff?r1=1.203&r2=1.204)
        planagg.c (r1.11 -> r1.12)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c.diff?r1=1.11&r2=1.12)
    pgsql/src/backend/optimizer/util:
        restrictinfo.c (r1.44 -> r1.45)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/restrictinfo.c.diff?r1=1.44&r2=1.45)
    pgsql/src/backend/utils/adt:
        selfuncs.c (r1.193 -> r1.194)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/selfuncs.c.diff?r1=1.193&r2=1.194)
    pgsql/src/include/executor:
        nodeIndexscan.h (r1.24 -> r1.25)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/nodeIndexscan.h.diff?r1=1.24&r2=1.25)
    pgsql/src/include/nodes:
        execnodes.h (r1.141 -> r1.142)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h.diff?r1=1.141&r2=1.142)
    pgsql/src/include/optimizer:
        paths.h (r1.88 -> r1.89)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/paths.h.diff?r1=1.88&r2=1.89)
    pgsql/src/include/utils:
        selfuncs.h (r1.25 -> r1.26)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/selfuncs.h.diff?r1=1.25&r2=1.26)

pgsql-committers by date:

Previous
From: dpage@pgfoundry.org (User Dpage)
Date:
Subject: pginstaller - pginst: Check for the version of Python that we actually
Next
From: tgl@svr1.postgresql.org (Tom Lane)
Date:
Subject: pgsql: Change seqscan logic so that we check visibility of all tuples on