Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozKPs-0003Lu-LY for pgsql-sql@arkaria.postgresql.org; Sun, 27 Nov 2022 16:22:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ozKPr-0000xh-6e for pgsql-sql@arkaria.postgresql.org; Sun, 27 Nov 2022 16:22:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozKPp-0000w7-UV for pgsql-sql@lists.postgresql.org; Sun, 27 Nov 2022 16:22:02 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ozKPi-00053w-Bd for pgsql-sql@lists.postgresql.org; Sun, 27 Nov 2022 16:22:00 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-14263779059so10514603fac.1 for ; Sun, 27 Nov 2022 08:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unochapeco.edu.br; s=google; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=2c2DXik5F+IChzwujpBLfDLC7872TQ/LALEtOmVMXVk=; b=SurMZOwy21LJLTnD5YunmfxRQEb+wLnLvCju7mGwq/VZiN5/wza4j3jWr+f+lrdMA5 2dN57fZ0jr8w8b07S+tMHzCFssbwQT5B9/AN0Ki1iy2UY9cHXzDTVslBewE7+BEvhXOZ G1szKeCaJOf0T1ykpRX6WjjExuKI55JZYare9bHM/MEk1MvhrYi/ADk66lMV6fFOzsuJ c6wfhdThVON0tQ9Ppum0YlvurkrSIZKKaU0GIzNo46gsO6Td2SzdUWGuisatbNKl6Acp N+FqSj4LDiQ8+q9xcjhKIhcdz/RBi1wVF0o+lPwIy3G5G0Ne1L/vvWwqeu2xwFp7/OSg 5cig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2c2DXik5F+IChzwujpBLfDLC7872TQ/LALEtOmVMXVk=; b=C2DguNVHlVWSCq1LxLbnubJiZiMH3kpMZJApZkys+G5yVMWxK6chNiywMKXxa8FjUK 2xPcxU89+lRtM9tWjCxukNlQU4Hgu/b7lsKRMWYErukLdhxqtP+hKNQmLZrKfiwUx+Wq eXKvKJzHD5rVwkFmGOUssaa5tRtwO7SHH2gO9a/vCaSnGfb2qcKxIQ3JPujBnhrYqB8V G1zTfe5p1071WjCAwQBmLsL4YDgb3qlrP3jpaME5osRHUKPQO5mndNlVjVXB5ci76Ms6 t3I9cghbjUwVputxvCojellwlsJiDsAC6BlJvRJfv6qyhmVdOiIHQxoXk46+xs7GJfWs D6Mw== X-Gm-Message-State: ANoB5pnL1/N6ldIhYvl77vExQbxp+n0WA0ptjFjprCr7KhkIj3jy8dr1 mrCg7I6Uj+1LjaVQsCJ0ksSVj2K0TyosxFUQxXvUeVqPGnR+OwzB8H01I1OkSXNcm6dtt0EEFf/ Heyh76PhsX5iDWEpxGBbpam+/gWJ/mnru/dbAvOSRjNAmpYXV/skvf8YJ17Ckz46B80BJ7KFIv4 ZYP1RIOxEuhRyoiQdwNsY= X-Google-Smtp-Source: AA0mqf5c1N9Ij6hhcOYw1Igqz9iEcxmSthoSxdWTtbehEBw2cT0PkF7pywIA27hfT1zfjlGo0nBfHw== X-Received: by 2002:a05:6870:9d18:b0:13d:9ace:3369 with SMTP id pp24-20020a0568709d1800b0013d9ace3369mr19425037oab.291.1669566112657; Sun, 27 Nov 2022 08:21:52 -0800 (PST) Received: from [192.168.0.106] ([186.250.91.103]) by smtp.gmail.com with ESMTPSA id t37-20020a05687060a500b0013bc95650c8sm4745662oae.54.2022.11.27.08.21.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Nov 2022 08:21:52 -0800 (PST) Date: Sun, 27 Nov 2022 13:21:44 -0300 From: William Alves Da Silva To: pgsql-sql@lists.postgresql.org, Ankit Kumar Pandey Message-ID: <2cc5a0eb-ef51-4561-9bc5-d015aab92228@Spark> In-Reply-To: <7f9f9b1d-b612-d0bd-4674-cfb5a8b2d343@gmail.com> References: <7f9f9b1d-b612-d0bd-4674-cfb5a8b2d343@gmail.com> Subject: Re: [QUESTION] Window function with partition by and order by X-Readdle-Message-ID: 2cc5a0eb-ef51-4561-9bc5-d015aab92228@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="63838e9d_79e2a9e3_263" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --63838e9d_79e2a9e3_263 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Ankit. This behavior is correct. This is because you are using ORDER BY in your = aggregation function. Looking at the documentation you will find the following quote: =22You can also control the order in which rows are processed by window f= unctions by using ORDER BY within OVER. (The window ORDER BY doesn't even= have to match the order in which the rows are produced).=22 So, if you use ORDER BY you are controlling how the row are processed. If you don't use, the result is like this: postgres=3D=23 select *, avg(id) over (partition by name) from my=5Fteste= ; =C2=A0id =7C name =7C avg ----+------+-------------------- =C2=A01 =7C A =7C 1.5000000000000000 =C2=A01 =7C A =7C 1.5000000000000000 =C2=A03 =7C A =7C 1.5000000000000000 =C2=A01 =7C A =7C 1.5000000000000000 =C2=A02 =7C B =7C 2.0000000000000000 (5 rows) -- Regards, William Alves On 27 Nov 2022 13:08 -0300, Ankit Kumar Pandey , = wrote: > Hello, > > While looking at aggregates in window function, I found something > unusual and would be glad I could get some clarification. > > Consider following table (mytable): > > id, name > > 1, A > > 1, A > > 2, B > > 3, A > > 1, A > > > select *, avg(id) over (partition by name, order by id) from mytable; > > Output: > > id, name, avg > > 1, A, 1 > > 1, A, 1 > > 1, A, 1 > > 3, A, 1.5 > > 2, B, 2 > > > Question is: Average of id for partition name (A) should be 6/4 =3D 1.5= > for all rows in that partition but this result is seen only at the last= > one row in partition (A). Am I missing here something=3F > > > Thanks > > > -- > Regards, > Ankit Kumar Pandey > > > --63838e9d_79e2a9e3_263 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Ankit.

This behavior is correct. This is because you are using ORDER BY in your = aggregation function.

Looking at the documentation you will find the following quote:
=22You can also control the order in which rows are processed by window f= unctions by using ORDER BY within OVER. (The window ORDER BY doesn't even= have to match the order in which the rows are produced).=22

So, if you use ORDER BY you are controlling how the row are processed.
If you don't use, the result is like this:

postgres=3D=23 select *, avg(id) over (partition by name) from my=5Fteste= ;
&=23160;id =7C name =7C avg
----+------+--------------------
&=23160;1 =7C A =7C 1.5000000000000000
&=23160;1 =7C A =7C 1.5000000000000000
&=23160;3 =7C A =7C 1.5000000000000000
&=23160;1 =7C A =7C 1.5000000000000000
&=23160;2 =7C B =7C 2.0000000000000000
(5 rows)&=23160;


--

Regards,

William Alves

On 27 Nov 2022 13:08 -0300, Ankit K= umar Pandey <itsankitkp=40gmail.com>, wrote:
Hello,

While looking at aggregates in window function, I found something
unusual and would be glad I could get some clarification.

Consider following table (mytable):

id, name

1, A

1, A

2, B

3, A

1, A


select *, avg(id) over (partition by name, order by id) from mytable;

Output:

id, name, avg

1, A, 1

1, A, 1

1, A, 1

3, A, 1.5

2, B, 2


Question is: Average of id for partition name (A) should be 6/4 =3D 1.5 for all rows in that partition but this result is seen only at the last one row in partition (A). Am I missing here something=3F


Thanks


--
Regards,
Ankit Kumar Pandey



--63838e9d_79e2a9e3_263--