X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 0F2CF5E3639 for ; Fri, 20 Aug 2004 15:43:18 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 35190-01 for ; Fri, 20 Aug 2004 18:43:11 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 22DA05E40AC for ; Fri, 20 Aug 2004 15:43:09 -0300 (ADT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id i7KIh8iG035233 for ; Fri, 20 Aug 2004 18:43:08 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id i7KITbEE029750 for pgsql-sql@postgresql.org; Fri, 20 Aug 2004 18:29:37 GMT From: Mischa Sandberg Reply-To: ischamay.andbergsay@activestateway.com User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 X-Newsgroups: comp.databases.postgresql.sql Subject: Re: olympics ranking query References: <41262968.2000507@zara.6.isreserved.com> <22979.1093020382@sss.pgh.pa.us> <412630C8.5000004@zara.6.isreserved.com> <28621.1093022468@sss.pgh.pa.us> In-Reply-To: <28621.1093022468@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 37 Message-ID: Date: Fri, 20 Aug 2004 18:29:38 GMT To: pgsql-sql@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.1 tagged_above=0.0 required=5.0 tests=NO_DNS_FOR_FROM X-Spam-Level: * X-Archive-Number: 200408/270 X-Sequence-Number: 18767 That 'running aggregate' notion comes up quite regularily, and it has a number of nonintuitive holes, to do with what happens when your ordering allows for ties. ASTRID had it, RedBrick SQL had it, the latest MSSQL has it ... not necessarily a recommendation. Tom Lane wrote: > David Garamond writes: > >>This is not quite the same. The ranks are sequential, but they skip, so >>as to match the number of participating countries. > > > Oh, I missed that bit. > > What you really want here is a "running sum" function, that is > > SELECT running_sum(numranker) as rank, * FROM > (same subselect as before) ss; > > There is no such thing in standard SQL, because it's fundamentally > dependent on the assumption of the input data coming in a particular > order, which is Evil Incarnate according to the relational worldview. > But it's not too hard to do in PLs that allow persistent state. > I recall Elein having exhibited one in plpython(?) not too long ago > --- you might find it on techdocs or varlena.com. > > You could brute-force it with a subselect (essentially "SUM(numranker) > over all rows that should precede this one") but that would involve > recomputing the whole subselect for each output row, which doesn't seem > very attractive. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings >