postgresql/src/backend/nodes
Tom Lane 608b167f9f Allow user control of CTE materialization, and change the default behavior.
Historically we've always materialized the full output of a CTE query,
treating WITH as an optimization fence (so that, for example, restrictions
from the outer query cannot be pushed into it).  This is appropriate when
the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE
query is non-recursive and side-effect-free, there's no hazard of changing
the query results by pushing restrictions down.

Another argument for materialization is that it can avoid duplicate
computation of an expensive WITH query --- but that only applies if
the WITH query is called more than once in the outer query.  Even then
it could still be a net loss, if each call has restrictions that
would allow just a small part of the WITH query to be computed.

Hence, let's change the behavior for WITH queries that are non-recursive
and side-effect-free.  By default, we will inline them into the outer
query (removing the optimization fence) if they are called just once.
If they are called more than once, we will keep the old behavior by
default, but the user can override this and force inlining by specifying
NOT MATERIALIZED.  Lastly, the user can force the old behavior by
specifying MATERIALIZED; this would mainly be useful when the query had
deliberately been employing WITH as an optimization fence to prevent a
poor choice of plan.

Andreas Karlsson, Andrew Gierth, David Fetter

Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
2019-02-16 16:11:12 -05:00
..
Makefile Introduce extensible node types. 2016-02-12 09:38:11 -05:00
README Rename nodes/relation.h to nodes/pathnodes.h. 2019-01-29 16:49:25 -05:00
bitmapset.c Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT. 2019-02-15 23:22:33 -05:00
copyfuncs.c Allow user control of CTE materialization, and change the default behavior. 2019-02-16 16:11:12 -05:00
equalfuncs.c Allow user control of CTE materialization, and change the default behavior. 2019-02-16 16:11:12 -05:00
extensible.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
list.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
makefuncs.c Make some small planner API cleanups. 2019-01-29 15:26:44 -05:00
nodeFuncs.c Refactor the representation of indexable clauses in IndexPaths. 2019-02-09 17:30:43 -05:00
nodes.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
outfuncs.c Allow user control of CTE materialization, and change the default behavior. 2019-02-16 16:11:12 -05:00
params.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
print.c Rename nodes/relation.h to nodes/pathnodes.h. 2019-01-29 16:49:25 -05:00
read.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
readfuncs.c Allow user control of CTE materialization, and change the default behavior. 2019-02-16 16:11:12 -05:00
tidbitmap.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
value.c Update copyright for 2019 2019-01-02 12:44:25 -05:00

README

src/backend/nodes/README

Node Structures
===============

Andrew Yu (11/94)

Introduction
------------

The current node structures are plain old C structures. "Inheritance" is
achieved by convention. No additional functions will be generated. Functions
that manipulate node structures reside in this directory.


FILES IN THIS DIRECTORY (src/backend/nodes/)

    General-purpose node manipulation functions:
	copyfuncs.c	- copy a node tree
	equalfuncs.c	- compare two node trees
	outfuncs.c	- convert a node tree to text representation
	readfuncs.c	- convert text representation back to a node tree
	makefuncs.c	- creator functions for some common node types
	nodeFuncs.c	- some other general-purpose manipulation functions

    Specialized manipulation functions:
	bitmapset.c	- Bitmapset support
	list.c		- generic list support
	params.c	- Param support
	tidbitmap.c	- TIDBitmap support
	value.c		- support for Value nodes

FILES IN src/include/nodes/

    Node definitions:
	nodes.h		- define node tags (NodeTag)
	primnodes.h	- primitive nodes
	parsenodes.h	- parse tree nodes
	pathnodes.h	- path tree nodes and planner internal structures
	plannodes.h	- plan tree nodes
	execnodes.h	- executor nodes
	memnodes.h	- memory nodes
	pg_list.h	- generic list


Steps to Add a Node
-------------------

Suppose you want to define a node Foo:

1. Add a tag (T_Foo) to the enum NodeTag in nodes.h.  (If you insert the
   tag in a way that moves the numbers associated with existing tags,
   you'll need to recompile the whole tree after doing this.  It doesn't
   force initdb though, because the numbers never go to disk.)
2. Add the structure definition to the appropriate include/nodes/???.h file.
   If you intend to inherit from, say a Plan node, put Plan as the first field
   of your struct definition.
3. If you intend to use copyObject, equal, nodeToString or stringToNode,
   add an appropriate function to copyfuncs.c, equalfuncs.c, outfuncs.c
   and readfuncs.c accordingly.  (Except for frequently used nodes, don't
   bother writing a creator function in makefuncs.c)  The header comments
   in those files give general rules for whether you need to add support.
4. Add cases to the functions in nodeFuncs.c as needed.  There are many
   other places you'll probably also need to teach about your new node
   type.  Best bet is to grep for references to one or two similar existing
   node types to find all the places to touch.


Historical Note
---------------

Prior to the current simple C structure definitions, the Node structures
used a pseudo-inheritance system which automatically generated creator and
accessor functions. Since every node inherited from LispValue, the whole thing
was a mess. Here's a little anecdote:

    LispValue definition -- class used to support lisp structures
    in C.  This is here because we did not want to totally rewrite
    planner and executor code which depended on lisp structures when
    we ported postgres V1 from lisp to C. -cim 4/23/90