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 1m0QCI-0007K2-4d for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Jul 2021 15:07:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m0QCG-0003zt-7F for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Jul 2021 15:07:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0QCF-0003zl-Ud for pgsql-hackers@lists.postgresql.org; Mon, 05 Jul 2021 15:07:43 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m0QCD-0004NF-Ln for pgsql-hackers@postgresql.org; Mon, 05 Jul 2021 15:07:43 +0000 Received: by mail-wr1-x42c.google.com with SMTP id t6so12543933wrm.9 for ; Mon, 05 Jul 2021 08:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=from:to:cc:subject:date:message-id:organization:in-reply-to :references:mime-version:content-transfer-encoding; bh=zj3yWH5s8QNaCThoB4nOwuywv4Sbjg5EnQxhOaTAQlY=; b=KrRMmFG23jAXIvWZqDULQRpUnRORY9xkpOlN/HTy/DZPXubE9z6Hm2EPeZQ4Dut7ng X4DiYPnIsc8f1sGJP0NxMZnH5yZQ8qyxQo3MOTU7I/RTsnuMXaFFATe8FZD9Y49qW3tk F0T/8VSM1K+qkRWZGy97ftkrfTiJOLfnERNV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :in-reply-to:references:mime-version:content-transfer-encoding; bh=zj3yWH5s8QNaCThoB4nOwuywv4Sbjg5EnQxhOaTAQlY=; b=I+Tp+Bf0Z3Z998hkiTienfI2XxMst70Yw71LwgoNLH8jO18YAP63970jzOAkE2eiRt dAB/mhqfEc5mqJevGRnN6sgdC01FjL/bNwGzTmUBH/uai8A/pNsSsJwTjwjM5msetkBE KV0KM/QacvAJonMR+uuYUTl5L1cuNaWSffs5qHeWLtVlJmNGaGSrDMlpP0OGRU2PV93j TFsv2QuwlYdstJ0+jytYq+ZuIYPvlUVH+pz2bz5wyAVq21/09pqVxKDFw5Zl6laoXI5t zZKEec2lxL79tX5cPbo+jsPAYLGg3tD3r377GIIV0n7VjHwEgMubkGJcSDExOqI9hi/X +Lgg== X-Gm-Message-State: AOAM5339/OkTnGl50Pahab358cL9YT/p/Ij2rgyxPIhwHSrnbdYBK9hD xTSCqBgHrQ1SP+oFLthDN3SfYpmV0SusW1fX X-Google-Smtp-Source: ABdhPJzm8u8IT7kMxjmd9TVg6r8qojeB5GAEdU9wTEbL2RJQRuMaOXDvuhwNRY2XNYHA/zEgGgqBsg== X-Received: by 2002:adf:f110:: with SMTP id r16mr16243213wro.271.1625497659760; Mon, 05 Jul 2021 08:07:39 -0700 (PDT) Received: from aivenronan.localnet (static-176-158-121-96.ftth.abo.bbox.fr. [176.158.121.96]) by smtp.gmail.com with ESMTPSA id c7sm13634787wrs.23.2021.07.05.08.07.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jul 2021 08:07:36 -0700 (PDT) From: Ronan Dunklau To: Pg Hackers , Ranier Vilela Cc: David Rowley Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates Date: Mon, 05 Jul 2021 17:07:27 +0200 Message-ID: <3730969.3kmaB5N0Mh@aivenronan> Organization: aiven In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Le lundi 5 juillet 2021, 16:51:59 CEST Ranier Vilela a =E9crit : > >Please find attached a POC patch to do just that. > > > >The switch to the single-datum tuplesort is done when there is only one > >attribute, it is byval (to avoid having to deal with copy of the >=20 > references >=20 > >everywhere) and we are not in bound mode (to also avoid having to move >=20 > things >=20 > >around). >=20 > Hi, nice results! >=20 > I have a few suggestions and questions to your patch: Thank you for those ! >=20 > 1. Why do you moved the declaration of variable *plannode? > I think this is unnecessary, extend the scope. Sorry, I should have cleaned it up before sending. >=20 > 2. Why do you declare a new variable TupleDesc out_tuple_desc at > ExecInitSort? > I think this is unnecessary too, maybe I didn't notice something. Same as the above, thanks for the two. >=20 > 3. I inverted the order of check at this line, I think "!node-bounded" is > more cheap that TupleDescAttr(tupDesc, 0) ->attbyval I'm not sure it matters since it's done once per sort but Ok >=20 > 4. Once that you changed the order of execution, this test is unlikely th= at > happens, so add unlikely helps the branch. Ok. >=20 > 5. I think that you add a invariant inside the loop > "if(node->is_single_val)"? > Would not be better two fors? Ok for me. >=20 > For you convenience, I attached a v2 version (with styles changes), please > take a look and can you repeat yours tests? Tested it quickly, and did not see any change performance wise that cannot = be=20 attributed to noise on my laptop but it's fine. Thank you for the fixes ! >=20 > regards, > Ranier Vilela =2D-=20 Ronan Dunklau