MIME-Version: 1.0
References: <17502-281a7aaacfaa872a@postgresql.org>
 <CABUevEz7t3OWxaSSVSHOxa5KcYioOk=yRwoL3iMViyZQ8m2wAw@mail.gmail.com>
 <CAGckUK2GLF=d9J5ErEWgK5x8ECqCw4equnq3jEzrqtfJw+iHYw@mail.gmail.com>
 <CAApHDvoR4BXm7oxSrYhpEAFOZ-qMPkkYnn14y6sxtPf=5w5OOw@mail.gmail.com>
 <CAApHDvqKO00nNQtchBs65VTfjEMUsYiB5r2P4VUreTdXE9RY1g@mail.gmail.com>
In-Reply-To: 
 <CAApHDvqKO00nNQtchBs65VTfjEMUsYiB5r2P4VUreTdXE9RY1g@mail.gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
Date: Mon, 30 May 2022 17:18:44 +0800
Message-ID: 
 <CAMbWs48yS=f8tj6zstiMd6yfV3U4YpssyB55PXqjcLUyUA5bww@mail.gmail.com>
Subject: Re: BUG #17502: View based on window functions returns wrong results
 when queried
To: David Rowley <dgrowleyml@gmail.com>
Cc: =?UTF-8?Q?Daniel_Farka=C5=A1?= <daniel.farkas@datoris.com>,
	Magnus Hagander <magnus@hagander.net>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000003948cd05e0372514"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMbWs48yS%3Df8tj6zstiMd6yfV3U4YpssyB55PXqjcLUyUA5bww%40mail.gmail.com>
Precedence: bulk

--0000000000003948cd05e0372514
Content-Type: text/plain; charset="UTF-8"

On Mon, May 30, 2022 at 9:12 AM David Rowley <dgrowleyml@gmail.com> wrote:

> The following is also pretty strange. Why should adding the SRF column
> to the ORDER BY change the number of output rows?
>
> postgres=# select distinct on (a) a,b, generate_Series(1,2) from ab
> order by a,b,3 desc;
>  a | b | generate_series
> ---+---+-----------------
>  1 | 1 |               2
>  2 | 1 |               2
> (2 rows)
>
>
> postgres=# select distinct on (a) a,b, generate_Series(1,2) from ab
> order by a,b;
>  a | b | generate_series
> ---+---+-----------------
>  1 | 1 |               1
>  1 | 1 |               2
>  2 | 1 |               1
>  2 | 1 |               2
> (4 rows)
>

This is indeed weird. This seems depends on at which plan level we add
ProjectSetPath. For the first query we insert ProjectSetPath at the
scan/join level, because the SRF is included in the ORDER BY, which
makes the SRF appear in the scan/join target. For the second query the
SRF is postponed to after the Sort.

Is this a bug we should fix?

Thanks
Richard

--0000000000003948cd05e0372514
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Mon, May 30, 2022 at 9:12 AM David Row=
ley &lt;<a href=3D"mailto:dgrowleyml@gmail.com">dgrowleyml@gmail.com</a>&gt=
; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The following is also pretty strange. Why should adding the SRF column<br>
to the ORDER BY change the number of output rows?<br>
<br>
postgres=3D# select distinct on (a) a,b, generate_Series(1,2) from ab<br>
order by a,b,3 desc;<br>
=C2=A0a | b | generate_series<br>
---+---+-----------------<br>
=C2=A01 | 1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02<br>
=C2=A02 | 1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02<br>
(2 rows)<br>
<br>
<br>
postgres=3D# select distinct on (a) a,b, generate_Series(1,2) from ab<br>
order by a,b;<br>
=C2=A0a | b | generate_series<br>
---+---+-----------------<br>
=C2=A01 | 1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01<br>
=C2=A01 | 1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02<br>
=C2=A02 | 1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01<br>
=C2=A02 | 1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02<br>
(4 rows)<br></blockquote><div><br></div><div>This is indeed weird. This see=
ms depends on at which plan level we add<br>ProjectSetPath. For the first q=
uery we insert ProjectSetPath at the<br>scan/join level, because the SRF is=
 included in the ORDER BY, which<br>makes the SRF appear=C2=A0in the scan/j=
oin target. For the second query the<br>SRF is postponed to after the Sort.=
<br><br>Is this a bug we should fix?<br><br>Thanks<br>Richard<br></div></di=
v></div>

--0000000000003948cd05e0372514--