pgsql: Teach planner and executor to handle ScalarArrayOpExpr as an

From: tgl(at)svr1(dot)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Teach planner and executor to handle ScalarArrayOpExpr as an
Date: 2005-11-25 19:47:50
Message-ID: 20051125194750.00FB3D6FA6@svr1.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2005-11-26 03:03:07 pgsql: Change seqscan logic so that we check visibility of all tuples on
Previous Message User Dpage 2005-11-25 11:58:45 pginstaller - pginst: Check for the version of Python that we actually