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