From: | Kenichiro Tanaka <kenichirotanakapg(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Wrong width of UNION statement |
Date: | 2020-06-04 14:53:15 |
Message-ID: | CALyBiZKyGeieR2vcqBJPC8a9RM2JFweCe4BOqPNe6HiVP+A-HA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> 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, 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
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-06-04 15:04:37 | Re: what can go in root.crt ? |
Previous Message | Tom Lane | 2020-06-04 14:26:11 | Re: Possible bug on Postgres 12 (CASE THEN evaluated prematurely) - Change of behaviour compared to 11, 10, 9 |