Hello,
Thank you for your quick response and sorry for my late reply.
> (I suppose you're using UTF8 encoding...)
It is right.
As you said, my encoding of database is UTF8.
>There's room for improvement there, but this is all bound up in the legacy
>mess that we have in prepunion.c.
At first,I think it is easy to fix it.
Because I think that it is easy to fix by calculating in the same way
as UNION ALL.
But ,now,I understand it is not so easy.
I'll report if I find some strong reason enough to throw away and
rewrite prepunion.c.
Thank you.
Regards
Kenichiro Tanaka.
2020年6月2日(火) 0:04 Tom Lane <tgl@sss.pgh.pa.us>:
>
> 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