|
|
Re: how to avoid multiple Like operators in a single query [message #436300 is a reply to message #436239] |
Tue, 22 December 2009 21:03 |
rleishman
Messages: 3728 Registered: October 2005 Location: Melbourne, Australia
|
Senior Member |
|
|
Using my crystal ball to deduce your problem, I guess you are running a query such as:
SELECT *
FROM tab
WHERE col LIKE :this
OR col LIKE :that
Which is slower than the individual queries:
SELECT *
FROM tab
WHERE col LIKE :this
SELECT *
FROM tab
WHERE col LIKE :that
You can try:
SELECT /*+USE_CONCAT*/ *
FROM tab
WHERE col LIKE :this
OR col LIKE :that
which will expand the OR out into a UNION statement, or you can recode it as a UNION yourself.
Ross Leishman
|
|
|
|
|
Re: how to avoid multiple Like operators in a single query [message #438415 is a reply to message #438347] |
Fri, 08 January 2010 15:53 |
rleishman
Messages: 3728 Registered: October 2005 Location: Melbourne, Australia
|
Senior Member |
|
|
Without an Explain Plan, it is very hard to say what is going on in any of these queries. But I suspect that your first query is benefiting from your very small table size (10 blocks).
The OP had a query with multiple LIKE clauses and was complaining about the performance. My deduction from this is that the LIKE clauses performed well individually, but not so good in combination.
Given THIS set of events, it is likely that Oracle is performing a single scan on just one of the columns, and USE_CONCAT can help encourage Oracle to index scan on both predicates, thereby giving performance comparable to the individual predicates.
I don't recall saying that USE_CONCAT should be standard operating procedure for any arbitrarily engineered multi-LIKE query. But if you want a broad sweeping statement, here's one: over large data volumes, if you have two very selective predicates combined in an OR statement, they will benefit from transformation into either an In-list iterator or a concatenation.
Ross Leishman
|
|
|
|
Re: how to avoid multiple Like operators in a single query [message #439438 is a reply to message #439435] |
Sat, 16 January 2010 17:30 |
rleishman
Messages: 3728 Registered: October 2005 Location: Melbourne, Australia
|
Senior Member |
|
|
Kevin Meade wrote on Sun, 17 January 2010 09:054) also, you can insert your values into a work table and join to the work table. The drawback with this solution is it makes your problem a two step process but its benefit is it is generic and can handle any number or values and can be optimized by the oracle optimizer using most of its tricks.
Kevin, that last one is a bit of a stretch. It assumes that the ORed predicates are 1) equality conditions, and 2) on the same column. Neither of these might be true. In fact, if driving the query off the these predicates is optimal, an INLIST Iterator is typically the best plan.
Ross Leishman
|
|
|
Re: how to avoid multiple Like operators in a single query [message #439441 is a reply to message #436230] |
Sat, 16 January 2010 17:45 |
|
Kevin Meade
Messages: 2103 Registered: December 1999 Location: Connecticut USA
|
Senior Member |
|
|
All true Ross. And I suppose it could be considered a stretch. I am glad you clarified this point for us.
In my defense however, whenever #4 is workable, it does in general provide the best performance because it turns the query into a true join and thus opens up join strategies for optimization.
I adint however, my position is tenuous. Let us leave it at #4 is an interesting alternative for those who wish to explore it. My expriences have been positive when I have used it.
Kevin
|
|
|