Add Trino 403 release notes

[colebow]

Description

Assemble the release notes for the upcoming Trino 403 release. Fixes #14878

Also removing one incorrect release note from 399, as due to a bug, the feature mentioned was not functional.

Non-technical explanation

N/A

Release notes

(x) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

Verification for each pull request

Format: maintainer, PR/issue number, ✅ / ❌ rn ✅ / ❌ docs
✅ rn - release note added and verified, or assessed to be not necessary, set to ❌ rn before completion
✅ docs - need for docs assessed and merged, or assessed to be not necessary, set to ❌ docs before completion

2 November 2022 ✅

@hashhar #14729 ✅ rn ✅ docs

3 November 2022 ✅

@losipiuk #14871 ✅ rn ✅ docs
@findepi #14804 ✅ rn ✅ docs
@sopel39 #14883 ✅ rn ✅ docs

4 November 2022 ✅

@sopel39 #10728 ✅ rn ✅ docs
@sopel39 #14820 ✅ rn ✅ docs
@sopel39 #14890 ✅ rn ✅ docs
@sopel39 #14902 ✅ rn ✅ docs
@kokosing #14774 ✅ rn ✅ docs
@findepi #14801 ✅ rn ✅ docs
@findepi #14434 ✅ rn ✅ docs
@findepi #14771 ✅ rn ✅ docs
@hashhar #14881 ✅ rn ✅ docs
@hashhar #14110 ✅ rn ✅ docs

5 November 2022 ✅

@martint #14896 ✅ rn ✅ docs
@martint #14872 ✅ rn ✅ docs
@findepi #14769 ✅ rn ✅ docs
@kokosing #10680 ✅ rn ✅ docs
@ebyhr #14905 ✅ rn ✅ docs

6 November 2022 ✅

@phd3 #14918 ✅ rn ✅ docs

7 November 2022 ✅

@kokosing #14921 ✅ rn ✅ docs
@ebyhr #14285 ✅ rn ✅ docs
@ebyhr #14899 ✅ rn ✅ docs
@ebyhr #14926 ✅ rn ✅ docs
@findepi #14932 ✅ rn ✅ docs
@hashhar #14930 ✅ rn ✅ docs
@hashhar #14931 ✅ rn ✅ docs
@ebyhr #14940 ✅ rn ✅ docs

8 November 2022 ✅

@ebyhr #14946 ✅ rn ✅ docs
@sopel39 #14867 ✅ rn ✅ docs
@phd3 #14708 ✅ rn ✅ docs
@sopel39 #14948 ✅ rn ✅ docs
@sopel39 #14887 ✅ rn ✅ docs
@martint #14914 ✅ rn ✅ docs
@martint #14889 ✅ rn ✅ docs
@ebyhr #14965 ✅ rn ✅ docs

9 November 2022 ✅

@findepi #14912 ✅ rn ✅ docs
@findepi #14910 ✅ rn ✅ docs
@kokosing #14951 ✅ rn ✅ docs
@raunaqmorarka #14966 ✅ rn ✅ docs
@findepi #14375 ✅ rn ✅ docs
@findepi #14911 ✅ rn ✅ docs
@findepi #14908 ✅ rn ✅ docs
@kokosing #14935 ✅ rn ✅ docs
@mdesmet #14950 ✅ rn ✅ docs
@ebyhr #14976 ✅ rn ✅ docs
@raunaqmorarka #14907 ✅ rn ✅ docs
@losipiuk #14974 ✅ rn ✅ docs

10 November 2022

@hashhar #14982 ✅ rn ✅ docs
@ebyhr #14938 ✅ rn ✅ docs
@kokosing #14949 ✅ rn ✅ docs
@sopel39 #14956 ✅ rn ✅ docs
@sopel39 #14873 ✅ rn ✅ docs
@hashhar #14882 ✅ rn ✅ docs
@hashhar #14632 ✅ rn ✅ docs
@hashhar #14792 ✅ rn ✅ docs
@phd3 #14532 ✅ rn ✅ docs
@arhimondr #14957 ✅ rn ➖ docs (#14861 - WIP)
@ebyhr #14990 ✅ rn ✅ docs
@ebyhr #14986 ✅ rn ✅ docs

11 November 2022 ✅

@martint #14913 ✅ rn ✅ docs
@ebyhr #14997 ✅ rn ✅ docs

13 November 2022 ✅

@ebyhr #15000 ✅ rn ✅ docs
@ebyhr #14864 ✅ rn ✅ docs

14 November 2022

@findepi #14816 ✅ rn ✅ docs
@findepi #14521 ✅ rn ✅ docs
@sopel39 #15006 ✅ rn ✅ docs
@sopel39 #15010 ✅ rn ✅ docs
@findepi #15008 ✅ rn ✅ docs
@findepi #14747 ✅ rn ✅ docs
@arhimondr #14941 ✅ rn ❌ docs
@phd3 #14830 ✅ rn ✅ docs
@losipiuk #14959 ✅ rn ✅ docs
@raunaqmorarka #15005 ✅ rn ✅ docs
@ebyhr #14848 ✅ rn ✅ docs
@martint #14958 ✅ rn ✅ docs

15 November 2022

@losipiuk #15016 ✅ rn ✅ docs
@sopel39 #14567 ✅ rn ✅ docs
@hashhar #14947 ✅ rn ✅ docs

[mosabua]

Looks good to go now.

[mosabua]

are we doing tomorrow?

[colebow]

If no, I'll update again.

[mosabua]

results of what ... the INSERT query or something else ?? Did it use to fail entirely or insert wrong data or something else?

[ebyhr]

results of what ... the INSERT query or something else ??

Results of INSERT

Did it use to fail entirely or insert wrong data or something else?

Inserted wrong data.

[colebow]

When bulk insert is enabled, the copy of the table that Trino loads ends up being empty. I think this is probably the most succinct way of explaining it without getting too into the weeds?

[ebyhr]

Please note that the wrong data were all null, not empty.

[findepi]

We should remove this. #15005 has no practical end-user implications that I am aware of, unless "bechmarks" is a "user".

cc @raunaqmorarka

[mosabua]

Well .. isn't this a performance improvement? Probably super small, but anyway. If so .. there is user facing impact. I would leave it.

cc @colebow

[findepi]

Not in any practical situation, so no, it's not user visible.

[mosabua]

Okay .. then I am not understanding this. Whats the point of having these stats then.. or fixing them. If there is no impact.

[raunaqmorarka]

The change is about fixing stats for DATE in a particular range (1900-01-02 to 1901-12-31). This range occurs in TPCDS and not having accurate stats results in bad plans for certain TPCDS queries.
I have no idea how to assess if this is possible in user data, however we know that ppl run TPC benchmarks and care about it running faster.

[findepi]

in any case, "Fix statistics for DATE columns" is bad wording, since nothing was broken and nothing got fixed.

you can change this to

"Add support for date column min/max statistics for values in range 1900-01-02 between 1901-12-31. Such dates occur in TPC-DS data sets."

This would be fathful, but also would tell the truth that real users don't care about this change, because no production workload will benefit. No-one runs TPC-DS as "production workloads".

[raunaqmorarka]

My suggested RN in the PR was Improve statistics for DATE columns in delta lake.
It's inaccurate to claim that no production workload can ever benefit from it. How do you know that there isn't some dimension table in "real" data which contains birth dates of ppl from that time ?

[findepi]

It's inaccurate to claim that no production workload can ever benefit from it.

Lack of release notes entry doesn't claim that.

Existence of release notes entry claims that there is a benefit.

How do you know that there isn't some dimension table in "real" data which contains birth dates of ppl from that time ?

How do you know there is?

[martint]

I agree with the rewording to make what was fixed more explicit. We should reserve judgement on whether such data appears in production workloads. That is very situational. There are many domains that deal with data in that range (and older) - historical weather record, etc.

[findepi]

For applications dealing with real historical data the fix won't really help, as it moves the min supported min value by just a year.