Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> Both build_simple_rel() and build_join_rel() allocate RelOptInfo using
> makeNode(), which returned a zeroed out memory. The functions then
> assign values like false, NULL, 0 or NIL which essentially contain
> zero valued bytes. This looks like needless work. So, we are spending
> some CPU cycles unnecessarily in those assignments. That may not be
> much time wasted, but whenever someone adds a field to RelOptInfo,
> those functions need to be updated with possibly a zero value
> assignment. That looks like an unnecessary maintenance burden. Should
> we just drop all those zero value assignments from there?
I'd vote for not. The general programming style in the backend is to
ignore the fact that makeNode() zeroes the node's storage and initialize
all the fields explicitly. The primary advantage of that, IMO, is that
you can grep for references to a particular field and understand
everyplace that affects it. As an example of the value, if you want to
add a field X and you try to figure out what you need to modify by
grepping for references to existing field Y, with this proposal you would
miss places that were node initializations unless Y *always* needed to be
initialized nonzero.
I could be convinced that it is a good idea to depart from this theory
in places where it makes a significant performance difference ... but
you've not offered any reason to think relnode.c is one.
regards, tom lane
