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