make_const --- don't repeat cache searches that aren't needed.

Thanks to Hiroshi

in the TupleDesc that the caller already has (for call from ExecMain) or
can make just as easily as ExecInitJunkFilter() can (for call from
ExecAppend).  Also, don't bother to build a junk filter for an INSERT
operation that doesn't actually need one, which is the normal case.

mdnblocks.  Bad enough it does an lseek, but to do it twice for no
reason...

that has no subplan --- saves a material amount of time for a simple
INSERT ... VALUES query.

In particular, don't bother to look up type information for attributes
where we're not actually going to use it, and avoid copying entire tlist
structure when it's not necessary.

during initial run formation by keeping both current run and next-run
tuples in the same heap (yup, Knuth is smarter than I am).  And, during
merge passes, make use of available sort memory to load multiple tuples
from any one input 'tape' at a time, thereby improving locality of
access to the temp file.

never to commit without running regress tests...

before calling execProject, when the outerPlan has returned zero tuples.
I took this out under the mistaken impression that the input tuple
couldn't be referenced by execProject if we weren't in GROUP BY mode.
But it can, if we're in an UPDATE or DELETE...

One, it now returns the previous hook. That way people don't have to dig
around in libpq-int.h for that information anymore. It previously
returned void, so there should be no incompatibilities.

Second, you cannot set the callback to NULL anymore. (Of course you can
still call it with NULL just to get the current hook.) The way libpq uses
the callback pointer, having a NULL there wasn't very healthy.

Peter Eisentraut