On 2015-12-04 12:50:09 -0500, Tom Lane wrote: > 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.
FWIW, for me it's still <= 64 bytes: struct Path { NodeTag type; /* 0 4 */ NodeTag pathtype; /* 4 4 */ RelOptInfo * parent; /* 8 8 */ ParamPathInfo * param_info; /* 16 8 */ bool parallel_aware; /* 24 1 */ /* XXX 7 bytes hole, try to pack */ double rows; /* 32 8 */ Cost startup_cost; /* 40 8 */ Cost total_cost; /* 48 8 */ List * pathkeys; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ /* size: 64, cachelines: 1, members: 9 */ /* sum members: 57, holes: 1, sum holes: 7 */ }; > 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? That part is obviously independently true, regardless of the size. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers