Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UhQyy-0004EM-1O for pgsql-sql@arkaria.postgresql.org; Tue, 28 May 2013 20:59:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UhQyw-0007Si-Pc for pgsql-sql@arkaria.postgresql.org; Tue, 28 May 2013 20:58:58 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UhQyu-0007Sa-KR for pgsql-sql@postgresql.org; Tue, 28 May 2013 20:58:56 +0000 Received: from mail.dhs-club.com ([208.69.229.2]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UhQyr-0000qn-GU for pgsql-sql@postgresql.org; Tue, 28 May 2013 20:58:55 +0000 Received: from [192.168.200.149] (c-68-56-244-59.hsd1.fl.comcast.net [68.56.244.59]) (authenticated bits=0) by mail.dhs-club.com (8.14.4/8.14.4) with ESMTP id r4SKwpBk017402 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 May 2013 20:58:52 GMT Message-ID: <51A51A8D.9060706@dhs-club.com> Date: Tue, 28 May 2013 16:58:53 -0400 From: Bill MacArthur User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Torsten Grust CC: pgsql-sql@postgresql.org Subject: Re: reduce many loosely related rows down to one References: <51A0660A.2010806@dhs-club.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 208.69.229.2 X-Pg-Spam-Score: -0.3 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org On 5/28/2013 11:04 AM, Torsten Grust wrote: > On 25 May 2013, at 9:19, Bill MacArthur wrote (with possible deletions): >> [...] >> select * from test; >> >> id | rspid | nspid | cid | iac | newp | oldp | ppv | tppv >> ----+-------+-------+-----+-----+------+------+---------+--------- >> 1 | 2 | 3 | 4 | t | | | | >> 1 | 2 | 3 | | | 100 | | | >> 1 | 2 | 3 | | | | 200 | | >> 1 | 2 | 3 | | | | | | 4100.00 >> 1 | 2 | 3 | | | | | | 3100.00 >> 1 | 2 | 3 | | | | | -100.00 | >> 1 | 2 | 3 | | | | | 250.00 | >> 2 | 7 | 8 | 4 | | | | | >> (8 rows) >> >> -- I want this result (where ppv and tppv are summed and the other distinct values are boiled down into one row) >> -- I want to avoid writing explicit UNIONs that will break if, say the "cid" was entered as a discreet row from the row containing "iac" >> -- in this example "rspid" and "nspid" are always the same for a given ID, however they could possibly be absent for a given row as well >> >> id | rspid | nspid | cid | iac | newp | oldp | ppv | tppv >> ----+-------+-------+-----+-----+------+------+---------+--------- >> 1 | 2 | 3 | 4 | t | 100 | 200 | 150.00 | 7200.00 >> 2 | 7 | 8 | 4 | | | | 0.00 | 0.00 > > One possible option could be > > SELECT id, > (array_agg(rspid))[1] AS rspid, -- (1) > (array_agg(nspid))[1] AS nspid, > (array_agg(cid))[1] AS cid, > bool_or(iac) AS iac, -- (2) > max(newp) AS newp, -- (3) > min(oldp) AS oldp, -- (4) > coalesce(sum(ppv), 0) AS ppv, > coalesce(sum(tppv),0) AS tppv > FROM test > GROUP BY id; > > > This query computes the desired output for your example input. > > There's a caveat here: your description of the problem has been > somewhat vague and it remains unclear how the query should > respond if the functional dependency id -> rspid > does not hold. In this case, the array_agg(rspid)[1] in the line > marked (1) will pick one among many different(!) rspid values. > I don't know your scenario well enough to judge whether this would be > an acceptable behavior. Other possible behaviors have been > implemented in the lines (2), (3), (4) where different aggregation > functions are used to reduce sets to a single value (e.g., pick the > largest/smallest of many values ...). > > Cheers, > --Torsten > Slick! Interesting usage scenarios for those aggregate functions array_agg and bool_or, one new to me and the other rarely used, and even for min and max which I never thought of using in this sense. I tried not be be overbearing with descriptive details hoping that somebody would look at the simplistic case and offer what might be considered an obscure way of implementing some of Postgres's handy features for an unusual problem. With a little tweaking for the exact nature of the environment, I am good to go. Thank you, Torsten! Bill MacArthur -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql