Return-Path: Received: from ensim.rackshack.net (root@localhost) by orafaq.net (8.11.6/8.11.6) with ESMTP id h9AJrev27288 for ; Fri, 10 Oct 2003 14:53:40 -0500 X-ClientAddr: 66.27.56.210 Received: from ns3.fatcity.com (rrcs-west-66-27-56-210.biz.rr.com [66.27.56.210]) by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id h9AJrdc27281 for ; Fri, 10 Oct 2003 14:53:39 -0500 Received: from ns3.fatcity.com (localhost.localdomain [127.0.0.1]) by ns3.fatcity.com (8.12.8/8.12.8) with ESMTP id h9AHA1O1028056 for ; Fri, 10 Oct 2003 10:10:03 -0700 Received: (from root@localhost) by ns3.fatcity.com (8.12.8/8.12.5/Submit) id h9AH0S6v026069 for oracle-l@orafaq.net; Fri, 10 Oct 2003 10:00:28 -0700 Received: by fatcity.com (05-Jun-2003/v1.0g-b73/bab) via fatcity.com id 005D2B74; Fri, 10 Oct 2003 09:54:41 -0800 Message-ID: Date: Fri, 10 Oct 2003 09:54:41 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: Jared.Still@radisys.com Sender: ml-errors@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: Jared.Still@radisys.com Subject: Re: Avoiding full table scan Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 73; ListGuru (c) 1996-2003 Bruce A. Bergman Precedence: bulk Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005CCE2A88256DBB_=" --=_alternative 005CCE2A88256DBB_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Downloaded and read last night. An excellent paper, as Tim stated. Now if I could just get an opportunity to do something like that... The downside of working for a small company. Jared Tim Gorman Sent by: ml-errors@fatcity.com 10/09/2003 06:09 PM Please respond to ORACLE-L =20 To: Multiple recipients of list ORACLE-L cc:=20 Subject: Re: Avoiding full table scan Same author (Jeff Maresh) has also published a new paper on physical=20 structure of data warehouses to accommodate the life cycle of data. It is = fantastic. I've published both papers ("Managing the Data Lifecycle" and "In Defense=20 of FULL table scans") on my website at "http://www.evdbt.com/papers.htm".=20 The "FULL table scan" paper is excellent, but I think the "Data Lifecycle" = paper is ground-breaking, covering topics that have not yet been treated=20 appropriately. I highly recommend them both... on 10/9/03 10:54 AM, Goulet, Dick at DGoulet@vicr.com wrote: Jack, In a recent copy of SELECT magazine there is a discussion in defense of= =20 full table scans. I believe you might find it VERY interesting. Although = I was aware of some of what the author spoke he put it in a vein that=20 makes extreme sense. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA=20 -----Original Message----- Sent: Thursday, October 09, 2003 10:49 AM To: Multiple recipients of list ORACLE-L Hi All,=20 I wish to avoid a full tablescan on the following data=20 V. Zanen=20 Zanen=20 Van Zanen=20 ..=20 ..=20 ..=20 Lot's more data=20 Select * from table where upper(name) like '%ZANEN%'=20 I could create a function based index on upper(name) but this does not=20 take care of the % and like operator.=20 Oracle has this (I believe it's called) context stuff that you can index=20 varchar fields etc. Is this the (only possible?) way to go?? TIA=20 Jack=20 --=_alternative 005CCE2A88256DBB_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Downloaded and read last night.

An excellent paper, as Tim stated.

Now if I could just get an opportuni= ty to do something like that...

The downside of working for a small = company.

Jared

Tim Gorman <tim@sagelogix.com&= gt;
Sent by: ml-errors@fatcity.com

10/09/2003 06:09 PM
Please respond to ORACLE-L

To: &nbs= p; Multiple recipients of list ORACLE-L <ORACLE-L@fa= tcity.com>
cc: &nbs= p;
Subject:= Re: Avoiding full table scan

Same author (Jeff Maresh) has also publis= hed a new paper on physical structure of data warehouses to accommodate the= life cycle of data. It is fantastic.

I've published both papers ("Managing the Data Lifecycle" and "In Defense o= f FULL table scans") on my website at "http://www.evdbt.com/papers.htm". &n= bsp;The "FULL table scan" paper is excellent, but I think the "Data Lifecyc= le" paper is ground-breaking, covering topics that have not yet been treate= d appropriately. I highly recommend them both...

on 10/9/03 10:54 AM, Goulet, Dick at DGoulet@vicr.com wrote:

Jack,

In a recent= copy of SELECT magazine there is a discussion in defense of full table sca= ns. I believe you might find it VERY interesting. Although I wa= s aware of some of what the author spoke he put it in a vein that makes ext= reme sense.

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Jack van Zanen [mailto:JACK@QUANTSYSTEMS.NL]
Sent: Thursday, October 09, 2003 10:49 AM
To: Multiple recipients of list ORACLE-L
Subject: Avoiding full table scan

Hi All,

I wish to avoid a full tablescan on the following data

V. Zanen
Zanen
Van Zanen
..
..
..
Lot's more data

Select * from table where upper(name) like '%ZANEN%'

I could create a function based index on upper(name) but this does not take= care of the % and like operator.

Oracle has this (I believe it's called) context stuff that you can index va= rchar fields etc. Is this the (only possible?) way to go??

TIA

Jack

--=_alternative 005CCE2A88256DBB_=-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: Jared.Still@radisys.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).