Joan,
Can't this be done as a series of ors instead of the union alls as this
would presumably reduce it to one full table scan of each table.
e.g.
SELECT T11.TRUNK TRUNK_FOUND
,T21.IDTARGET_ID
,T21.SSN TARGET_SSN
,T21.FULLNAME
ORACLE-L [EMAIL PROTECTED]
sfaroult@orio cc:
le.com Subject: Re: slow query help
Sent by:
[EMAIL PROTECTED]
om
18/12/2002
07
Title: RE: slow query help
Joan,
Here is a suggestion ...
if this is going to be your most used part, I'd look into Intermedia ... you'll have a lot more options to work with and they will work good.
Until then, I'd recommend replacing instr() with appropriate LIKE clause because at-least
Raj,
I thought it would only do the union all if it was able to use an index and
all the instr's look as though they'd stop that. Even then I thought it was
generally just rule that would do that unless you used the use_concat hint.
I can't see why a full table scan of each wouldn't be
Joan Hsieh wrote:
Hi,
This is the query bothered us very much recently. It run at least 15
min. and sometimes crashed the temp tablespace. Do you have any idea how
to make it run better. Our developer tried used two cursors to compare
the result, but the result is not optimized. We tried
]
sfaroult@orio cc:
le.com Subject: Re: slow query help
Sent
Title: RE: slow query help
It need not be generatd by a tool, I have worked for a blood bank in one of my previous projects. When it comes to matching a donor in th records, you have to take a lot of precautions to see if you have a duplicate donor etc.
To me this seems to be logic to find
recipients of list
ORACLE-L [EMAIL PROTECTED]
sfaroult@orio cc:
le.com Subject: Re: slow query help
Sent by:
[EMAIL PROTECTED]
om
18/12/2002
-
From: Mark Richard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 17, 2002 4:51 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: slow query help
I tend to agree with Stephane...
It looks like that query was possibly generated by a tool. If not you
should go talk
