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 <t...@sss.pgh.pa.us>: > > Kenichiro Tanaka <kenichirotanak...@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
