Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fDcwQ-0006Il-VX for pgsql-hackers@arkaria.postgresql.org; Tue, 01 May 2018 21:36:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fDcwP-0001R8-UW for pgsql-hackers@arkaria.postgresql.org; Tue, 01 May 2018 21:36:05 +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 1fDcwP-0001Qy-Ky for pgsql-hackers@lists.postgresql.org; Tue, 01 May 2018 21:36:05 +0000 Received: from mail-pf0-x236.google.com ([2607:f8b0:400e:c00::236]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fDcwI-0000d8-N5 for pgsql-hackers@postgresql.org; Tue, 01 May 2018 21:36:05 +0000 Received: by mail-pf0-x236.google.com with SMTP id v63so9970141pfk.8 for ; Tue, 01 May 2018 14:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nXTYNZ9nWxj0xiL5RCVtXt2+5KMnRPcV71nJ2sfCTkg=; b=PDmjybJqjOxjlick7qejbjkspbzLuD7e32mnDU6AShGMSiLL30qL5BbQiayLLdZk7h P/I1rvsgLAYWJ1YW9SU7McrU1E3mgnv5DkwD/iVbnP60EVsQVkS37/ZGnsnRc+QNqil7 kBR4oYPXzXCSA0FwZWz99JhJF8ysh7UXOZrWASuWNm8WRzFeKbPDaWyUDa5xFwPnrJKb BXzVKmUr+Rq0JWfc/5oqo4wNb9wUYYzZqM6WME3qx8YiYDsOlthWFZQHFyyAt2LYu8eB v56uamJ38+iAoTP4FeVR3UlMHVNG91v8rskdvWVf+lr2DyfSbOmP7zop5I+r6/pq/XWX cXzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nXTYNZ9nWxj0xiL5RCVtXt2+5KMnRPcV71nJ2sfCTkg=; b=KbF5SXUmtTYHg+sGEX5cKKYfhIIDMJCfgWvHGCqvaEvDe68XcuD7nA5MCf+SyPjjcM 8sUUNndE4AXTKqZzeped9qf1AmiGAyTm58NscabxZGoATByqcrWMiHHsnqqbtZ7nlOik IbTVnSyBn1UOb5z9AsfKJ/qjwJFzqprcoiW+biChsVNUhVPL4KWTTojsjoYcYSOnA+ky gkGJXGK3G1xiDK9pP4zl4Gf5eA3bypTAKbsGjkyd9DLWzBIgYLCKuOTQcjWl5TKnATxz 4u+y8zheEDLZ93L/rm32wiYrbJVayvCoxKx5QIux+iRCyFORi17o+dFAD75rf6TiSqMU 8BKw== X-Gm-Message-State: ALQs6tBz0rvU0ro4bfIJgfqRpdcRy54Bl1kTjYhUsraHchQxbF2tpC08 L3jOfrwslzt/ikO3PosPo8p3bV+K X-Google-Smtp-Source: AB8JxZoO6Oxtxv0JgbSda2YkJ5HudPAkagMzjhwZ6XiG9NVS02A/E+EWDmcnDS7qyZJa1ONAdBp5fw== X-Received: by 2002:a65:65c4:: with SMTP id y4-v6mr9888469pgv.369.1525210556587; Tue, 01 May 2018 14:35:56 -0700 (PDT) Received: from [192.168.2.121] (24-113-186-59.wavecable.com. [24.113.186.59]) by smtp.gmail.com with ESMTPSA id t23-v6sm18339599pgu.41.2018.05.01.14.35.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 May 2018 14:35:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Parallel Aggregates for string_agg and array_agg From: Mark Dilger In-Reply-To: <20180501211147.3balprbggw3pdpxk@alap3.anarazel.de> Date: Tue, 1 May 2018 14:35:46 -0700 Cc: Tom Lane , David Rowley , Alvaro Herrera , Stephen Frost , Tomas Vondra , PostgreSQL-development Content-Transfer-Encoding: 7bit Message-Id: References: <20180327002617.fjgkgxmeojfkti7b@alvherre.pgsql> <13700.1522162694@sss.pgh.pa.us> <1C2959D0-56F2-4067-B2AC-DF9A3B1D0FB5@gmail.com> <20180501211147.3balprbggw3pdpxk@alap3.anarazel.de> To: Andres Freund X-Mailer: Apple Mail (2.3124) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On May 1, 2018, at 2:11 PM, Andres Freund wrote: > > Hi, > > On 2018-05-01 14:09:39 -0700, Mark Dilger wrote: >> I don't care which order the data is in, as long as x[i] and y[i] are >> matched correctly. It sounds like this patch would force me to write >> that as, for example: >> >> select array_agg(a order by a, b) AS x, array_agg(b order by a, b) AS y >> from generate_a_b_func(foo); >> >> which I did not need to do before. > > Why would it require that? Rows are still processed row-by-row even if > there's parallelism, no? I was responding in part to Tom's upthread statement: Your own example of assuming that separate aggregates are computed in the same order reinforces my point, I think. In principle, anybody who's doing that should write array_agg(e order by x), array_agg(f order by x), string_agg(g order by x) because otherwise they shouldn't assume that; It seems Tom is saying that you can't assume separate aggregates will be computed in the same order. Hence my response. What am I missing here? mark