pgsql-server/ oc/src/sgml/release.sgml rc/back ...

Started by Tom Laneover 23 years ago2 messagescomitters
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@postgresql.org 03/01/20 13:55:08

Modified files:
doc/src/sgml : release.sgml
src/backend/executor: nodeHashjoin.c nodeMergejoin.c
nodeNestloop.c
src/backend/nodes: copyfuncs.c equalfuncs.c list.c outfuncs.c
src/backend/optimizer: README
src/backend/optimizer/geqo: geqo_eval.c geqo_main.c
src/backend/optimizer/path: allpaths.c costsize.c indxpath.c
joinpath.c joinrels.c
src/backend/optimizer/plan: createplan.c initsplan.c planmain.c
planner.c setrefs.c subselect.c
src/backend/optimizer/prep: Makefile prepunion.c
src/backend/optimizer/util: clauses.c joininfo.c pathnode.c
relnode.c tlist.c var.c
src/backend/rewrite: rewriteManip.c
src/backend/utils/adt: selfuncs.c
src/include/nodes: nodes.h parsenodes.h pg_list.h relation.h
src/include/optimizer: joininfo.h pathnode.h planmain.h
planner.h prep.h subselect.h tlist.h
var.h
src/include/utils: selfuncs.h
src/test/regress/expected: subselect.out
Added files:
src/backend/optimizer/prep: prepjointree.c

Log message:
IN clauses appearing at top level of WHERE can now be handled as joins.
There are two implementation techniques: the executor understands a new
JOIN_IN jointype, which emits at most one matching row per left-hand row,
or the result of the IN's sub-select can be fed through a DISTINCT filter
and then joined as an ordinary relation.
Along the way, some minor code cleanup in the optimizer; notably, break
out most of the jointree-rearrangement preprocessing in planner.c and
put it in a new file prep/prepjointree.c.

#2Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#1)
Re: pgsql-server/ oc/src/sgml/release.sgml rc/back ...

I have marked IN/NOT IN performance problem as fixed in 7.4! Great job.

---------------------------------------------------------------------------

Tom Lane wrote:

CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@postgresql.org 03/01/20 13:55:08

Modified files:
doc/src/sgml : release.sgml
src/backend/executor: nodeHashjoin.c nodeMergejoin.c
nodeNestloop.c
src/backend/nodes: copyfuncs.c equalfuncs.c list.c outfuncs.c
src/backend/optimizer: README
src/backend/optimizer/geqo: geqo_eval.c geqo_main.c
src/backend/optimizer/path: allpaths.c costsize.c indxpath.c
joinpath.c joinrels.c
src/backend/optimizer/plan: createplan.c initsplan.c planmain.c
planner.c setrefs.c subselect.c
src/backend/optimizer/prep: Makefile prepunion.c
src/backend/optimizer/util: clauses.c joininfo.c pathnode.c
relnode.c tlist.c var.c
src/backend/rewrite: rewriteManip.c
src/backend/utils/adt: selfuncs.c
src/include/nodes: nodes.h parsenodes.h pg_list.h relation.h
src/include/optimizer: joininfo.h pathnode.h planmain.h
planner.h prep.h subselect.h tlist.h
var.h
src/include/utils: selfuncs.h
src/test/regress/expected: subselect.out
Added files:
src/backend/optimizer/prep: prepjointree.c

Log message:
IN clauses appearing at top level of WHERE can now be handled as joins.
There are two implementation techniques: the executor understands a new
JOIN_IN jointype, which emits at most one matching row per left-hand row,
or the result of the IN's sub-select can be fed through a DISTINCT filter
and then joined as an ordinary relation.
Along the way, some minor code cleanup in the optimizer; notably, break
out most of the jointree-rearrangement preprocessing in planner.c and
put it in a new file prep/prepjointree.c.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073