So over in my private branch where I've been fooling around with upper
planner pathification, I've been sweating bullets to avoid enlarging the
size of struct Path, because I was aware that common path types like
IndexPath and AppendPath were already a power-of-2 size (at least on
64-bit machines), meaning that palloc'ing them would cost twice as much
space if I added any fields.
When I got around to merging up to HEAD, I found this in commit f0661c4e8:
@@ -753,6 +753,7 @@ typedef struct Path RelOptInfo *parent; /* the relation this path can build */
ParamPathInfo*param_info; /* parameterization info, or NULL if none */
+ bool parallel_aware; /* engage parallel-aware logic? */ /* estimated size/costs for path (see
costsize.cfor more info) */ double rows; /* estimated number of result tuples */
which means Robert has already blown the planner's space consumption out
by close to a factor of 2, and I should stop worrying. Or else he should
start worrying. Do we really need this field? Did anyone pay any
attention to what happened to planner space consumption and performance
when the parallel-scan patch went in? Or am I just too conditioned by
working with last-century hardware, and I should stop caring about how
large these nodes are?
While I'm bitching about this: a field added to a struct as fundamental
as Path ought to have a pretty well-defined meaning, and this does not
as far as I can tell. There was certainly no documentation worthy of
the name added by the above commit. What is the semantic difference
between a Path with this flag set and the identical Path without?
Likewise for struct Plan?
regards, tom lane