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.c for 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers