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 1pDKxG-00021n-55 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 07:46:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pDKxE-0008Bi-7y for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 07:46:24 +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 1pDKxD-0008BZ-TK for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 07:46:23 +0000 Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pDKxB-0001vX-MJ for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 07:46:22 +0000 Received: by mail-pf1-x431.google.com with SMTP id 6so22004755pfz.4 for ; Wed, 04 Jan 2023 23:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=deszijW0mcBCNsboH7HvHZhdl+lyH5nSVgLx+0tiilU=; b=OJtwVrXOkSc8LPBVHChyMxMrcM4QZqMLbVvclw5ZaLmr+Wev1Ea55fNTHylPCjoWB8 7nNLdQZTenJRQLvfYyehyCXkVEJwR7vfXw1e/xPq/kFWf2PN0nYxlOMp2hRtXKYvw78I CdHaFolcHBmk5NQzPdTrue/YAV4/HuKVCxojNd7Ny0n7DWx/bsYzLMINMzCeYDuJIvl/ i2NINots/Hm09mUrQD2mT/yBVFFD85HP16KrRy0xRuvAyvVgKCr6w6YPKVyzPeHtPf2U 5nxGK/+wRXW6G7Mw2eyxih+EirbbVgc2dKq03qz5/YJVDYtgY3IC6adhAO9JPifHm3fN ba+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=deszijW0mcBCNsboH7HvHZhdl+lyH5nSVgLx+0tiilU=; b=KPcpOUbtGhurlJL39SesxIPkv+nUCPVzU2fUCJUKgDDuNcKiknVcwLPn0DiI544ba+ 3EpAQpAq1gUQ9fPyXZs7neME1dwc/cFRcANxIuFj2NPmzV3m/76WwTjN67llH+ih1d8w vGMcfNlzGk0EOTC/+OVLJrv1eb+HkJJuMB2TguJ/l4UFj5u6B6lGyplhdhvJ9sro4zBV w7rYPYeQVd7ZTHqjEb+kUMqBaGw0ladEeIecWqUSO6i8Rw1hl6FwwSNYREPMq2uUOElv bJ2ykbWKyPCPdoIQXRRz/AZlrZ0uBooXjUH7eYQ5lwfK6xTNTOPo1UYP94N414/MEPr7 FZBA== X-Gm-Message-State: AFqh2kporJr8GgqbQiipphdY0sIFw+g/2qKff+yj6HjunD5Ur04r9BPD F0ladT7g6OmUJtu5xXCVeHE= X-Google-Smtp-Source: AMrXdXsYh64h8ll0IMOumN3yGG+ipA6+RKZBw8roHfjZlafTs4fggXkA+GxSG5AcxM++CR94yAJrMQ== X-Received: by 2002:aa7:99cf:0:b0:581:c741:f908 with SMTP id v15-20020aa799cf000000b00581c741f908mr26232261pfi.33.1672904780225; Wed, 04 Jan 2023 23:46:20 -0800 (PST) Received: from [10.0.2.15] ([106.202.139.208]) by smtp.gmail.com with ESMTPSA id w4-20020aa79544000000b0058173c4b3d1sm16259348pfq.80.2023.01.04.23.46.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 23:46:19 -0800 (PST) Message-ID: Date: Thu, 5 Jan 2023 13:16:15 +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: Todo: Teach planner to evaluate multiple windows in the optimal order To: David Rowley Cc: Vik Fearing , pghackers References: <83d80853-a45c-d85c-68eb-59acfe7fb5fb@gmail.com> <7f77ee7d-bd04-d8e2-bb34-42395fd1f7c2@gmail.com> <6ebcc137-45ea-6373-e3e1-3c304c452e1f@gmail.com> <441d135e-1941-c3ef-1649-18c3e8811549@postgresfriends.org> <9620d994-b89a-2dcf-fca5-821e19d56858@gmail.com> Content-Language: en-US From: Ankit Kumar Pandey In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 05/01/23 12:53, David Rowley wrote: > > We *can* reuse Sorts where a more strict or equivalent sort order is > available. The question is how do we get the final WindowClause to do > something slightly more strict to save having to do anything for the > ORDER BY. One way you might think would be to adjust the > WindowClause's orderClause to add the additional clauses, but that > cannot be done because that would cause are_peers() in nodeWindowAgg.c > to not count some rows as peers when they maybe should be given a less > strict orderClause in the WindowClause. Okay, now I see issue in my approach. > It might be possible to adjust create_one_window_path() so that when > processing the final WindowClause that it looks at the DISTINCT or > ORDER BY clause to see if we can sort on a few extra columns to save > having to do any further sorting. We just *cannot* make any > adjustments to the WindowClause's orderClause. > This is much better solution. I will check create_one_window_path for the same. -- Regards, Ankit Kumar Pandey