Hello,Ashutosh Thank you for your response. >We already have that infrastructure, IIUC through commit That's good!
>Can we use that to fix this bug? I'll try it. But this is my first hack,I think I need time. Regards Kenichiro Tanaka 2020年6月8日(月) 22:11 Ashutosh Bapat <ashutosh.bapat....@gmail.com>: > > On Mon, Jun 1, 2020 at 8:35 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > 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, > > We already have that infrastructure, IIUC through commit > > commit c596fadbfe20ff50a8e5f4bc4b4ff5b7c302ecc0 > Author: Robert Haas <rh...@postgresql.org> > Date: Mon Mar 19 11:55:38 2018 -0400 > > Generate a separate upper relation for each stage of setop planning. > > Can we use that to fix this bug? > > -- > Best Wishes, > Ashutosh Bapat