Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fRn7z-0003Ye-TZ for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Jun 2018 23:18:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fRn7x-0007UF-KB for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Jun 2018 23:18:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fRn7x-0007U5-CK for pgsql-hackers@lists.postgresql.org; Sat, 09 Jun 2018 23:18:33 +0000 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fRn7q-0005S1-5c for pgsql-hackers@postgresql.org; Sat, 09 Jun 2018 23:18:32 +0000 Received: by mail-wm0-x241.google.com with SMTP id v131-v6so9904518wma.1 for ; Sat, 09 Jun 2018 16:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qtK0Ky1HoIhHxsKZGTlaWX+kE2B7WpZkd4Vt/DucJtU=; b=ml84xJ9SKFZtL3zbuKeuuo4eYPuOBhJy/kqxx4wWkkz6HitPvM1aSnPe1kc1MPdgC5 TvzZDg45QEgxhfv3Y0heCpBZ+KX0zcdZtnCbTnGgxhoNoOlpHZW+uzObCXX8wfxMyoFX nduSnEeC+UEp+soBlrOqiXFMuIczTc207bUdo9LlSiESqXi6XpZYNB5/9n5TSS5W08A9 EmFNL0vSP664D++lnpK2W3XY7GFLGZd46PdH8tLrPVZlRGpGi92E5b1JUBFHK5Uoj7oY 2B0gG/uvVIe4rnKf/834UjfbiaVxAyU9Xx/i9AtYlOjt7wt6jSOlroGUn3y5TTySyyJP Aa6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qtK0Ky1HoIhHxsKZGTlaWX+kE2B7WpZkd4Vt/DucJtU=; b=PZqnbwIVQShsAJ+p3HEL1WaCT1qn2ESESipZcfo2HFsOz1L8XnIjPvK/5vpSh7L4jE zyf4WX7zweToLScZ6gA1FloZr3DUBTgSxLUyClbYMDu5OAPKXSkX9afERi4tPWdP60d2 HJm1Oad26/6zuPUKF66/EE0x2oG6dQIRduw8Hh7KE3AnwEbNvD1QQ6/AunyOO7Ji1bek 4JOSkgSImdDNXQHnE6l4IiLVOUt7B/kIHOFs7C9P8YGZqncTx7/3VHCYSoKB6KCb64Gx 71wGzV93QunqRyBEri3FZkvTZqTc6Vpin3ALBK3CynPM2ene/DCkmeQnaFFDiz/O3JQG p9aw== X-Gm-Message-State: APt69E1v31+0QBTcMlP+YSQSy6IWCcKrZ+8G0OixsYPFt/1rLHcHk64t ctUxeIrLG/foLt35/xk8JpFkdSNz+fljHfzpJv/u+1iCzg75aMejnRpjVcJfzlIOyEh5MOoVKN4 uNvqQ2pgC6a02Bms2BeAe3tDorqCf+SuUvfSQ7LVv7zhuxKqmfyXiRqYsjGpcli2YMTsB2g2UHo gJOj/vEnB2 X-Google-Smtp-Source: ADUXVKK++bqNXrtfBrskzwBX1HEqWDun4FZDCNrdHP7L2h65FBS+yTYjwLOX4LBPb5e+ddtOK1f57g== X-Received: by 2002:a1c:e48a:: with SMTP id b132-v6mr4674071wmh.129.1528586303503; Sat, 09 Jun 2018 16:18:23 -0700 (PDT) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id r11-v6sm22607891wrn.34.2018.06.09.16.18.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jun 2018 16:18:22 -0700 (PDT) Subject: Re: POC: GROUP BY optimization From: Tomas Vondra To: Teodor Sigaev , Pgsql Hackers References: <7c79e6a5-8597-74e8-0671-1c39d124c9d6@sigaev.ru> <97d148b7-f3e7-1c39-07fd-74cbc66f6ec9@sigaev.ru> <6d1e0cdb-dde3-f62a-43e2-e90bbd9b0f42@2ndquadrant.com> <7edddb4f-9ddd-561d-2bde-47340f91d2a0@2ndquadrant.com> <2cb99655-7ae7-ec8d-2c74-3fea58987104@sigaev.ru> <6dddcce6-0d91-1868-794a-4d61dc5516f0@2ndquadrant.com> Message-ID: <523d1f60-c60c-5c8c-8cc5-c6c078970da6@2ndquadrant.com> Date: Sun, 10 Jun 2018 01:18:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 06/09/2018 08:09 PM, Tomas Vondra wrote: > > /snip/ > > 4) when adding Sort for grouping, try producing the right output order > (if the ORDER BY was specified) > BTW I've just realized we already do something similar in master. If you run a query like this: SELECT a, b, count(*) FROM t GROUP BY b, a ORDER BY a; we will actually plan it like this: QUERY PLAN --------------------------- GroupAggregate Group Key: a, b -> Sort Sort Key: a, b -> Seq Scan on t (5 rows) I.e. we already do reorder the group clauses to match ORDER BY, to only require a single sort. This happens in preprocess_groupclause(), which also explains the reasoning behind that. I wonder if some of the new code reordering group pathkeys could/should be moved here (not sure, maybe it's too early for those decisions). In any case, it might be appropriate to update some of the comments before preprocess_groupclause() which claim we don't do certain things added by the proposed patches. This probably also somewhat refutes my claim that the order of grouping keys is currently fully determined by users (and so they may pick the most efficient order), while the reorder-by-ndistinct patch would make that impossible. Apparently when there's ORDER BY, we already mess with the order of group clauses - there are ways to get around it (subquery with OFFSET 0) but it's much less clear. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services