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 1ozKRg-0003Rt-0v for pgsql-sql@arkaria.postgresql.org; Sun, 27 Nov 2022 16:23:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ozKRe-0003Pr-SP for pgsql-sql@arkaria.postgresql.org; Sun, 27 Nov 2022 16:23:54 +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 1ozKRe-0003Ph-Gi for pgsql-sql@lists.postgresql.org; Sun, 27 Nov 2022 16:23:54 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ozKRb-00054L-MR for pgsql-sql@lists.postgresql.org; Sun, 27 Nov 2022 16:23:53 +0000 Received: by mail-ed1-x52a.google.com with SMTP id f7so12506428edc.6 for ; Sun, 27 Nov 2022 08:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reddoc.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FotTbwSuoHsgVNdVlF4vkzFqlX3PjztvB38fExBjQPo=; b=JGcsQm8OJ9DwVyO8kZD/Vp3PLnSWWxsdu7qc5a+rhdYfNhgGlc4Z/JVdxB1T9vXr+H DLOqim5Zh8dNHqc4uYdyDVC+ZzhmcTfPFkyb1Dqq0+NVZML1wnjsjJu7bE2j20Bt4QXk MnEvSST5/Y4MAUWJxCQgrS1/wQp2Rj3YGUmOM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FotTbwSuoHsgVNdVlF4vkzFqlX3PjztvB38fExBjQPo=; b=jBHdIEkVVm9Wk37kb4Tagxm1GgS0KvI35KsxhiHZYW2UCYd+FMTR78lVSyuA5YC8KD Gpl1NFfPcRTMnkymxqvwFS+Dz6GoisVwiM5+2u935mUFSU93UvNsjddnJgBqt51nCkc5 dr+gVzr93VHLNQqsezPif1OlA/IIcwhJ6QKcv2AvaZSgL2YMKyIZwguvFY5Ffzzu78K9 85CIm6Czp58UiDYA3jXqxsw2sRzBMzjhiminQ3ohdQ0wNWbavi+jaWSYROCUUDyT+Bd8 3C0c2/EZUaEPV8c6lSb6DMlT98sy7CPQ8SqBjXzkh9M65+7pds+S058NjOQZMKwPGlpU uV6g== X-Gm-Message-State: ANoB5pk9IOrcgs25zyPoCsmUBNaYjOn1wBpah8NrxFRNwOgaEgasBRg8 89kLRnMx2MKvoQeZ0m1l/oaBwTrvN5gYPDmlsBRFeq94Pwrec1um X-Google-Smtp-Source: AA0mqf5n8cwPgVE+CTdl89rnoijlg+v05yQZeLxTNl5N3vUo6YY9YXLQJ5s817KxreNGPFvom31KDbNnr++G3wpeWUQ= X-Received: by 2002:a50:fd98:0:b0:467:5f07:b575 with SMTP id o24-20020a50fd98000000b004675f07b575mr44316850edt.65.1669566229288; Sun, 27 Nov 2022 08:23:49 -0800 (PST) MIME-Version: 1.0 References: <7f9f9b1d-b612-d0bd-4674-cfb5a8b2d343@gmail.com> In-Reply-To: <7f9f9b1d-b612-d0bd-4674-cfb5a8b2d343@gmail.com> From: Samed YILDIRIM Date: Sun, 27 Nov 2022 18:23:38 +0200 Message-ID: Subject: Re: [QUESTION] Window function with partition by and order by To: Ankit Kumar Pandey Cc: pgsql-sql@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000006ac4105ee762ef3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000006ac4105ee762ef3 Content-Type: text/plain; charset="UTF-8" Hello Ankit, It is absolutely expected behaviour of a window function with ORDER BY clause. The default frame clause of window definition is *RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW*. If you add an ORDER BY clause in a window definition, PostgreSQL takes the current row and all rows before it within the partition into calculation. If you don't add, it means all rows within the partition are peers, and PostgreSQL uses all rows for calculation. I'm putting the related part from the documentation and its link below. The default framing option is RANGE UNBOUNDED PRECEDING, which is the same > as RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW; it sets the frame to > be all rows from the partition start up through the current row's last peer > (a row that the window's ORDER BY clause considers equivalent to the > current row; all rows are peers if there is no ORDER BY). https://www.postgresql.org/docs/15/sql-select.html#SQL-WINDOW Best regards. Samed YILDIRIM On Sun, 27 Nov 2022 at 18:08, 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 = 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? > > > Thanks > > > -- > Regards, > Ankit Kumar Pandey > > > > --00000000000006ac4105ee762ef3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ankit,

It is absol= utely expected behaviour of a window function with ORDER BY clause. The def= ault frame clause of window definition is RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. If you add an ORDE= R BY clause in a window definition, PostgreSQL takes the current row and al= l rows before it within the partition into calculation. If you don't ad= d, it means all rows within the partition are peers, and PostgreSQL uses al= l rows for calculation. I'm putting the related part from the documenta= tion and its link below.

The default framing option is RANGE UNBOUNDED PRECEDING, which= is the same as RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW; it sets = the frame to be all rows from the partition start up through the current ro= w's last peer (a row that the window's ORDER BY clause considers eq= uivalent to the current row; all rows are peers if there is no ORDER BY).
=C2=A0

Best regards.
Samed YILDIRIM


On Sun, 27 Nov 2022 at 18:08, Ankit Kumar Pandey <itsankitkp@gmail.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?


Thanks


--
Regards,
Ankit Kumar Pandey



--00000000000006ac4105ee762ef3--