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.oss@gmail.com>:
>
> On Mon, Jun 1, 2020 at 8:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > 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,
>
> We already have that infrastructure, IIUC through commit
>
> commit c596fadbfe20ff50a8e5f4bc4b4ff5b7c302ecc0
> Author: Robert Haas <rhaas@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