Re: Size of Path nodes

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