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 1ozKvq-00050V-JQ for pgsql-sql@arkaria.postgresql.org; Sun, 27 Nov 2022 16:55: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 1ozKvp-0006pE-GO for pgsql-sql@arkaria.postgresql.org; Sun, 27 Nov 2022 16:55:05 +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 1ozKvp-0006lt-33 for pgsql-sql@lists.postgresql.org; Sun, 27 Nov 2022 16:55:05 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ozKvm-0005Pt-Qv for pgsql-sql@lists.postgresql.org; Sun, 27 Nov 2022 16:55:04 +0000 Received: by mail-pg1-x534.google.com with SMTP id r18so7922939pgr.12 for ; Sun, 27 Nov 2022 08:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=EN0Mq0QJZ1W7sc9MREUmAQP91oCDiqfMZKl4PWH7Cr0=; b=bUvT9xcZp6vT1lW0J6ImHNmn+JI+q7MT1JuowBFZeOaYOPCQNYDpcQpK1xcadBSQYF L31Vfv1n4y/SJX5EXN/njsgyGe+gxW9NWpgg13mQNulUxbpwQBmW4/bhZqew95I214l2 XUPvNlUq1m6iZSpGJC7BVJ5UW7BOj1/xJe5TIll1PxjsdVA8+VXpPcCyxnGvzdFE15IU ekXb9KW8xX2LhaaycxVLQ+KWjsp0ANVvUVFBYCIJAG12yeW1RSQlsD4dtjdiZW6pPi+e xhszsY2tUq5vYShfeYIB+5DZQR3S0qp+PmokL5efjm87oJEcOg7XJNnr+Qd2dCfjNK3G JqSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=EN0Mq0QJZ1W7sc9MREUmAQP91oCDiqfMZKl4PWH7Cr0=; b=1VfplYI69tIwQlCpFMOJDLD3yOYLtXw1G8um1nD6J9E7UMbQlngVhtoCFcq+WqFWIG 2DdZVAKDav3Pzv1d1/BSFCwvcPsAjzQt6Y6tdHvcxr9wB+GGhmZzaGB6QHJdvZGnH5nu lUzdK+JsA1p0GfSLYxqUIgvglHKJ/A5065VGQqMYK2cCv6c+5xIuC8ojaEVe0FKV7Ajs FJsywzyt1gjOmVNdjWhl0uN7PpMqXRraWYzl97hubhcbyXIp5o3rJ4YMb9cHWqC8eCc8 ddgjxiKBoiV7J/qFXQQ1OxCEHjnsyTAV3QTwYKybj6O45EsARq74+IjdGr/9YCR0w3g0 hH6A== X-Gm-Message-State: ANoB5pnxy5X16ApctoPHlE9FRQ1X6PMGL1jxmCMsxJb3hgSQLhhuLJ3V aJzhqyLB5FAVqJCkd7uVWr8FLNg4KIw= X-Google-Smtp-Source: AA0mqf65k4S5RIwotQ50YI/9vitiq+zAz031OWz8KJ2WuNdp7pW+RKrGOEnF8Y9L7JzEJo6s6mq2BQ== X-Received: by 2002:a05:6a00:17a3:b0:56b:b37d:9857 with SMTP id s35-20020a056a0017a300b0056bb37d9857mr29597504pfg.12.1669568102034; Sun, 27 Nov 2022 08:55:02 -0800 (PST) Received: from [10.0.2.15] ([122.163.232.215]) by smtp.gmail.com with ESMTPSA id v19-20020a1709028d9300b00172e19c5f8bsm7055024plo.168.2022.11.27.08.55.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 08:55:01 -0800 (PST) Content-Type: multipart/alternative; boundary="------------yIrjVhr639x3ckpPccCuYO0E" Message-ID: <795fdbcd-57ec-0cd2-d7d4-9949848aa2f0@gmail.com> Date: Sun, 27 Nov 2022 22:24:58 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [QUESTION] Window function with partition by and order by Content-Language: en-US To: Samed YILDIRIM Cc: pgsql-sql@lists.postgresql.org References: <7f9f9b1d-b612-d0bd-4674-cfb5a8b2d343@gmail.com> From: Ankit Kumar Pandey In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------yIrjVhr639x3ckpPccCuYO0E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 27/11/22 21:53, Samed YILDIRIM wrote: > 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 > > > Thanks, this makes sense. -- Regards, Ankit Kumar Pandey --------------yIrjVhr639x3ckpPccCuYO0E Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 27/11/22 21:53, Samed YILDIRIM wrote:
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).
 

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 = 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



Thanks, this makes sense.
-- 
Regards,
Ankit Kumar Pandey
--------------yIrjVhr639x3ckpPccCuYO0E--