Re: Wrong width of UNION statement

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(dot)bapat(dot)oss(at)gmail(dot)com>:
>
> On Mon, Jun 1, 2020 at 8:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Kenichiro Tanaka <kenichirotanakapg(at)gmail(dot)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 <rhaas(at)postgresql(dot)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