Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tBAjS-002HFH-No for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Nov 2024 10:36:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tBAjP-00DCAc-VM for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Nov 2024 10:36:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tBAjP-00DCAT-Kt for pgsql-hackers@lists.postgresql.org; Wed, 13 Nov 2024 10:36:16 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBAjN-001eOg-GD for pgsql-hackers@postgresql.org; Wed, 13 Nov 2024 10:36:14 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2feeb1e8edfso87903451fa.1 for ; Wed, 13 Nov 2024 02:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731494172; x=1732098972; darn=postgresql.org; 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=yMNwVpgbHbt3PRKcj2vANCi3OlUxbOSyZbmTayp33Zo=; b=MyK6HyPqPqV2ubI2TQsi2SAnfybQAOuCNcN2WkY4YT2dy2h9mZJarU7z6NeOoI1PeT eFyX03coUUlbh/cslVoSVNUYp4IrhiqLqWgI7B+BwD/MeCYqyZxwAimYt8iXMMOWv1AC oF3c3gbq8lWBAqwmGbIRGVOeDtLY6xUkKEWcR6pinGhuLm+lQHjuomJpnNpDmD72k3QX aXlV2sTqkI1JewtO5JUx5j46tD8uCjXPXQyotUPw2EsOW4iYcVpck/BcsZFikhErP+YM FHxEaxDqbMUc4lQ6brJp/wDnIhRos4ec9r/YuGK33K4kKRxzGedxB404QK8Ip2KUCH9V Ue2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731494172; x=1732098972; 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=yMNwVpgbHbt3PRKcj2vANCi3OlUxbOSyZbmTayp33Zo=; b=hUFkngetd78PaTgBGD7gkF3Wvq02+X0D3FHEZrEwvronU55dVlMQThlUUvg3O6YQEZ 0UDIUvJPSYG027RRohWpjOkmaFAUJgKDcczrntOHPuKse+gneVguoOrEgxDoAfFBJYS8 tiP+LYrVf3dJLHn2HP4un/OTHNGhCCIQIlUmhSvaM9l0OsUCUmRrZoVDQO/aRuVZ3JgH tffQSUsTD+I2GtWLqB21GCarEXg1nC4zqLTy+7q7MeescIJnhfMvNiiD5fiWD8D3e09t VqOU+fFdibnvdpg1IMAdE5STXFYpU7524RUQWrVl4au4xKtkx62EPVe/Y7HzB9ccfH8B C0xw== X-Gm-Message-State: AOJu0Yycc9JV43OezycjbsUUcKJNQDOKhNsQuQKfN+gZ0ZbD3tLEaaqr p5ow6uMI3r5Gg3sOo1kVti+zge7tmyJcsbyqg2iDQVIqDU8eX/Gi X-Google-Smtp-Source: AGHT+IGEtp+wR3VbwMUyCeL7/9E/DJJuRp/FJYxYJKevpMziRvKP/rCrKgauG8EgFqaXeOSDQGligA== X-Received: by 2002:ac2:4c36:0:b0:53d:a025:1142 with SMTP id 2adb3069b0e04-53da02512e6mr1396933e87.54.1731494171427; Wed, 13 Nov 2024 02:36:11 -0800 (PST) Received: from [10.4.15.162] ([93.174.131.141]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53d82685eafsm2124192e87.75.2024.11.13.02.36.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2024 02:36:10 -0800 (PST) Message-ID: Date: Wed, 13 Nov 2024 17:36:10 +0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Reordering DISTINCT keys to match input path's pathkeys To: Richard Guo Cc: PostgreSQL-development , David Rowley References: <0fc11a92-f6e4-4d8c-b882-91283ef54bce@gmail.com> Content-Language: en-AU From: Andrei Lepikhov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/13/24 13:49, Richard Guo wrote: > On Mon, Oct 28, 2024 at 6:15 PM Andrei Lepikhov wrote: >> On 6/7/24 16:46, Richard Guo wrote: >>> This patch does not apply any more, so here is a new rebase, with some >>> tweaks to the comments. > >> This patch needs a minor rebase again. >> After skimming the code, I want to say that it looks good. But maybe to >> avoid one more *_reordering GUC - it would be better to cover all path >> key reorderings under a single GUC. > > Thanks for reviewing this patch. After some consideration, I think > it's not too complex to also apply this optimization to DISTINCT ON. > The parser already ensures that the DISTINCT ON expressions match the > initial ORDER BY expressions; we just need to ensure that the > resulting pathkey list from the reordering matches the original > distinctClause pathkeys, while leaving the remaining pathkeys > unchanged in order. Please see attached. Thanks, I'll discover it later. BTW have you ever thought about one more, cost-based reordering strategy? For now, we can reorder GROUP-BY and distinct clauses according to two orderings: 1) ORDER-BY order and 2) order derived from the underlying query tree. In thread [1], I try to add one more strategy that minimises the number of comparison operator calls. It seems that it would work the same way with the DISTINCT statement. Do you think it make sense in general and can be a possible direction of improvement for the current patch? > > I'm not sure about merging these two 'reordering' GUCs into one. > While they may look similar, they apply to very different scenarios. > However, I'm open to other suggestions. Sure, they enable different optimisations. But, they enable highly specialised optimisations. Having two GUCs looks too expensive. Moreover, this stuff is cost-based and should work automatically. So, I treat these GUCs as mostly debugging or last-chance stuff used to disable features during severe slowdowns or bugs. It might make sense to group them into a single 'Clause Reordering' parameter. [1] https://www.postgresql.org/message-id/flat/8742aaa8-9519-4a1f-91bd-364aec65f5cf%40gmail.com -- regards, Andrei Lepikhov