Kenichiro Tanaka <kenichirotanakapg@gmail.com> writes:
> I think table column width of UNION statement should be equal one of UNION ALL.
I don't buy that argument, because there could be type coercions involved,
so that the result width isn't necessarily equal to any one of the inputs.
Having said that, the example you give shows that we make use of
pg_statistic.stawidth values when estimating the width of immediate
relation outputs, but that data isn't available by the time we get to
a UNION output. So we fall back to get_typavgwidth, which in this
case is going to produce something involving the typmod times the
maximum encoding length. (I suppose you're using UTF8 encoding...)
There's room for improvement there, but this is all bound up in the legacy
mess that we have in prepunion.c. For example, because we don't have
RelOptInfo nodes associated with individual set-operation outputs, it's
difficult to figure out where we might store data about the widths of such
outputs. Nor could we easily access the data if we had it, since the
associated Vars don't have valid RTE indexes. So to my mind, that code
needs to be thrown away and rewritten, using actual relations to represent
the different setop results and Paths to represent possible computations.
In the meantime, it's hard to get excited about layering some additional
hacks on top of what's there now.
regards, tom lane