Dynamic configuration updates is a pretty unorthodox, if you ask me.
Perhaps having an extra configuration file where such dynamically calculated
values will go, might be a bit more conventional, don't you think? Basically,
just leave the hawq-site along, and anything you need to modify should go
When doing 'hawq init', we will check the segments number and dynamic to
decide some property values, for example 'default_segment_num',
'hawq_rm_nvseg_perquery_perseg_limit'. These properties will be write back
to hawq-site.xml by 'hawq config' command.
Another situation you mentioned is when we
Thanks for the explanation, Radar. But I am talking about hawq-site.xml, which
is being re-written and the original content is copied under hawq-site.xml.org
I guess I pointed to a wrong function, as I see that _write_config() is doing
exactly what you said.
Generating of the new files might be
