Received: (qmail 15584 invoked from network); 8 Aug 2011 17:20:24 -0500
Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180)
  by static-ip-85-25-126-90.inaddr.intergenia.de with SMTP; 8 Aug 2011 17:20:18 -0500
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F24BEE398C2;
 Mon,  8 Aug 2011 18:20:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org;
 s=turing; t=1312842018; bh=2eOdYM8kPYk2ZFoFnCtgKe9nMvbc+IqMHDCYFko1
 a9E=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References:
	 In-Reply-To:Content-Type:Content-Transfer-Encoding:Sender:Reply-To:
	 List-help:List-unsubscribe:List-Id:List-subscribe:List-owner:
	 List-post:List-archive; b=hUWMyp+Os/4hwibD+91lPiMv5gTBtRaFbibAkNnd
 HoXfFN0bar+ZyO0ChOxCmrdQR2VRsiWCOeHTQ4cloCGeTYg2OBw2/InU8xXq/9KnhOU
 1zXmPkCWGJxgELzSJGT54bwOKynD06nsMgYFfAZmBloXaYERGUlt+QQnoq4BcMHk=
X-Virus-Scanned: Debian amavisd-new at localhost.localdomain
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id SGikjpMt-fDv; Mon,  8 Aug 2011 18:20:17 -0400 (EDT)
Received: from turing.freelists.org (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 10B6FE395F2;
 Mon,  8 Aug 2011 18:19:35 -0400 (EDT)
Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 08 Aug 2011 18:18:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6D9BEE38CF9	for <oracle-l@freelists.org>; Mon,  8 Aug 2011 18:18:53 -0400 (EDT)
Received: from turing.freelists.org ([127.0.0.1])	by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id I5nohsG1Vv0G for <oracle-l@freelists.org>;	Mon,  8 Aug 2011 18:18:53 -0400 (EDT)
Received: from mail-yw0-f51.google.com (mail-yw0-f51.google.com [209.85.213.51])	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E607AE38CC6	for <oracle-l@freelists.org>; Mon,  8 Aug 2011 18:18:52 -0400 (EDT)
Received: by ywb26 with SMTP id 26so3351222ywb.10        for <oracle-l@freelists.org>; Mon, 08 Aug 2011 15:18:51 -0700 (PDT)
Received: by 10.42.88.205 with SMTP id d13mr6214362icm.154.1312841931480;        Mon, 08 Aug 2011 15:18:51 -0700 (PDT)
Received: from [172.16.30.218] (207-114-255-174.static.twtelecom.net [207.114.255.174])        by mx.google.com with ESMTPS id a11sm4511265ibg.38.2011.08.08.15.18.50        (version=TLSv1/SSLv3 cipher=OTHER);        Mon, 08 Aug 2011 15:18:50 -0700 (PDT)
Message-ID: <4E4060C6.2090300@ardentperf.com>
Date: Mon, 08 Aug 2011 17:18:46 -0500
From: Jeremy Schneider <jeremy.schneider@ardentperf.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: mwf@rsiz.com
CC: oracle-l@freelists.org, ChrisDavid.Taylor@ingrambarge.com
Subject: Re: Wow - has anyone used ROW_NUMBER() to get around using a UNION statement when UNION ALL doesn't work??
References: <C5533BD628A9524496D63801704AE56D6A315EBA35@SPOBMEXC14.adprod.directory>	<60AAF908-AF26-4150-A894-E96164ECAD15@centrexcc.com>	<C5533BD628A9524496D63801704AE56D6A315EBA72@SPOBMEXC14.adprod.directory>	<65857EE5-361A-4BB4-B88C-644E3871FFF1@centrexcc.com>	<C5533BD628A9524496D63801704AE56D6A315EBA9F@SPOBMEXC14.adprod.directory>	<CAGXkmiu=qZzLQWmeZZO_N96EaoUg-QYwr5cf2xTty1+w2K6anQ@mail.gmail.com>	<38D36890-880B-4D0F-B582-2FD94734D54B@ingrambarge.com>	<DUB111-W8638692899EFAD9D7B2E33A13F0@phx.gbl>	<E5A9AB01-DF92-4472-A56E-8506626CC53C@ingrambarge.com> <CAGXkmithjZ7QNcogMGXUoR7qUq-TYXnimQcTr_UfwVA0M7-+3g@mail.gmail.com> <00b901cc55e8$0ef2ab60$2cd80220$@rsiz.com>
In-Reply-To: <00b901cc55e8$0ef2ab60$2cd80220$@rsiz.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-archive-position: 37909
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: jeremy.schneider@ardentperf.com
Precedence: normal
Reply-To: jeremy.schneider@ardentperf.com
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <oracle-l-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@freelists.org?Subject=subscribe>
List-owner: <mailto:steve.adams@ixora.com.au>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l

On 8/8/2011 11:27 AM, Mark W. Farnham wrote:
> In the event that you know a subset of the columns of a UNION ALL projection
> such that ordering by the column subset guarantees that duplicates appear
> together, then you can generate that special case of UNION ALL to UNION
> de-duplication at a lower cost. Chris has related one such mechanism, using
> the ROW_NUMBER() analytical function. It may have been unclear that he was
> relying on a subset of the columns of the projection. If he needed all the
> columns for the grouping, his mechanism would be at best a tie (and I write
> that in the sense that the best you can do in any transfer of energy is have
> zero increase in entropy, except you really can only break even in the math
> and in reality you always lose.)

I think that in his original email, Chris said he included all the
columns in the "partition by" clause.


On 8/5/2011 1:35 PM, Taylor, Chris David wrote:
> Now, I put the query containing the UNION ALL in an INNER select, and
> I select all columns from it PLUS the ROW_NUMBER() function
> partitioning by all the columns and applying an order by to the
> function and call this column “ROW_KEY” (not very original I know).


Which is why there are so many questions about this. As Mark has pointed
out, if you're partitioning on all the columns then you're doing exactly
the same sort that's the UNION is doing. Something just isn't quite
right about the results; both methods should be doing nearly the
identical work.

Or to put it another way, if manually sorting all the records and
removing dups addes 0 seconds and 0 TEMP tablespace to the subquery
without the ROW_NUMBER() analytic clause, then either the sort is not
really happening (the fastest way to do anything) or there's something
wrong with the UNION which ought to be running in the same amount of
time and resources. At least this is how it seems to me, and might be
the reason there are so many questions.

-Jeremy

-- 
http://www.ardentperf.com
+1 312-725-9249

Jeremy Schneider
Chicago

--
http://www.freelists.org/webpage/oracle-l


