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 1esVxu-0002yO-DB for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Mar 2018 15:54:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1esVxt-0007sG-49 for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Mar 2018 15:54:21 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1esVxp-0007JJ-J2 for pgsql-hackers@lists.postgresql.org; Sun, 04 Mar 2018 15:54:17 +0000 Received: from mail-wr0-x235.google.com ([2a00:1450:400c:c0c::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1esVxl-0007Ds-AI for pgsql-hackers@postgresql.org; Sun, 04 Mar 2018 15:54:15 +0000 Received: by mail-wr0-x235.google.com with SMTP id m12so14737002wrm.13 for ; Sun, 04 Mar 2018 07:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KDIvnwJl6G9SZc+oDn8sHX2zkm1k+7zSz4o0BRGHD9o=; b=kgSd1w6DqEKh837CBXvlpgnZoV24puO6w1DNlHKE2hBd5XEuHgyvI0M7skQmlrBNhP 4pW+zYmpBZLwiejVUyUBG4S0jPsai0LIcqK32yk0EGzUBib880kwP8bl5NEq6ZGTW80I 5NEWC2n9YAegxF3097GMBhcrV1mGitkE4+Jn5PzBRHM5vRVCjhsliDX98oV6Z8Q6XdHS vHoUtmbMn5gS2QvrH4qaTdaJFpGIM3K/hPZh3tccG8ea62EXa4IUb1MBUTjQUx4QDOZW E4KLNpofC24yA7tM8gMRhh/+gvcDO1zVtM2C4dMoblWUli3OElxBBxJazb0hcmwnA1PX q9wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KDIvnwJl6G9SZc+oDn8sHX2zkm1k+7zSz4o0BRGHD9o=; b=gibP1LBo1r6K4wIIQLfznSlyaGgwqEJ/eF4uKI4hwcVYIXsSk9X+X2xxXPNxOYkQJq Ku7H5hfgkMnFyhYYCohi3n5GsKJLr9xi6yMxJNxLowm5PjhEYOqRhPST8CKyU55iN2MT PG4Uj4hH4G+Ymr15NJdS0SNQSw5DFRG+AMH1RmZ0cXc0FODvjQy9YilpSDvoutXwWpwX oi4G9rAWbJACY/mqpzujkKGkaXHEvaq32y84bPGFbsxp6ZPtyk5Qk1hVgDd+MHNiUSUN 47BIvbbBhK0Y8Xu2GxjWGCpwuUAuTkKJtp8S+wJXGTz7OcTtbTpuBKkluWKzUL7GGKr7 YyHw== X-Gm-Message-State: APf1xPBtxtr4iZsI/IX80MAHY54MOW/t3B3Bd5xhPUNhhPI/bc4D6xVh PNNZk42dviDJ0NmAkVjCsGiefJDpsWu4wA9wuv56VxE6IN7v2IJ4YqZPdtIBW3RqW3HEr9jKihT oASmcfMmR9tEhSN1GlZXrMsDf2e1M7QXyy/EOWFi9mRGjXaqGYkaYYWnCMuSEoOmjoPYVNA89Q6 tldH3RuJHL X-Google-Smtp-Source: AG47ELsXLm5GnRJwg3eVxKjO/w7+Tzc6gHstEbogF+b3uF3hNQm5pFB5IM/S6zce1MqHSYY8B7SPwQ== X-Received: by 10.223.132.167 with SMTP id 36mr11199829wrg.227.1520178850938; Sun, 04 Mar 2018 07:54:10 -0800 (PST) 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 i66sm1655383wmd.0.2018.03.04.07.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Mar 2018 07:54:10 -0800 (PST) Subject: Re: Parallel Aggregates for string_agg and array_agg To: David Rowley , Andres Freund Cc: PostgreSQL-development References: <20180301212631.kede4nyuttzxwoxq@alap3.anarazel.de> From: Tomas Vondra Message-ID: Date: Sun, 4 Mar 2018 16:54:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, I've looked at the rebased patch you sent yesterday, and I do have a couple of comments. 1) There seems to be forgotten declaration of initArrayResultInternal in arrayfuncs.c. I suppose you've renamed it to initArrayResultWithSize and moved it to a header file, and forgotten to remove this bit. 2) bytea_string_agg_deserialize has this comment: /* * data: technically we could reuse the buf.data buffer, but that is * slightly larger than we need due to the extra 4 bytes for the cursor */ I find the argument "it has 4 extra bytes, so we'll allocate new chunk" somewhat weak. We do allocate the memory in 2^n chunks anyway, so the new chunk is likely to be much larger anyway. I'm not saying we need to reuse the buffer, IMHO the savings will be non-measurable. 3) string_agg_transfn and bytea_string_agg_transfn say this" /* * We always append the delimiter text before the value text, even * with the first aggregated item. The reason for this is that if * this state needs to be combined with another state using the * aggregate's combine function, then we need to have the delimiter * for the first aggregated item. The first delimiter will be * stripped off in the final function anyway. We use a little cheat * here and store the position of the actual first value (after the * delimiter) using the StringInfo's cursor variable. This relies on * the cursor not being used for any other purpose. */ How does this make the code any simpler, compared to not adding the delimiter (as before) and adding it when combining the values (at which point you should know when it's actually needed)? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services