Some additional comments ...
Robert Haas <robertmh...@gmail.com> writes:
> With regards to your question, for each type of plan node, there is an
> associated "plan state" node. This is an important distinction
> because, IIUC, plans can be reused, so plan state contains the
> information that might need to be reset on each run.
Yeah. The plan tree is supposed to be read-only so far as the executor
is concerned, so it needs a parallel "plan state" tree to hold its
runtime state.
> I believe a tuple projection
> is what you get when you do something like SELECT
> generate_series(1,10) FROM tbl - the set-returning function has to be
> "projected" in multiple tuples.
I think "projection" is a term out of relational theory, referring to
any sort of tuple-by-tuple manipulation of the data. For instance,
if you have a row "a, b, c" and you compute "a, c+1" based on that,
that's a projection. ExecProject() does this in the general case.
The business with SRFs in a targetlist possibly producing multiple
rows is a PostQUEL-ism that doesn't have any standard technical name
that I know of.
> A qual is a filter condition, e.g. in SELECT * FROM tbl WHERE
> x = 1, the "x = 1" part is a qual.
qual = qualifier. We use that term with various shades of meaning;
notably an indexqual is a qualifier that is useful for searching an
index. Large parts of the planner also use the term "clause" to mean
about the same thing.
> It's helpful to grep src/include
> for the structures in question;
Here's my single biggest tip for newcomers to the Postgres source:
if you don't use ctags, glimpse, or some other tool that can quickly
show you all references to a given identifier, go out and get one.
It's one of the easiest ways to learn about things.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
